使用 Node.js 引擎强制执行 Semver 策略

如何解决使用 Node.js 引擎强制执行 Semver 策略

强制执行更新的 (Node.js) 引擎版本时的政策是什么？ 是 semver MAJOR 还是 semver MINOR？

上下文：我是 package with 2k stars on github（每周 3 万次下载）的作者，我最近实施了 Node.js v14（因为我开始使用可选的链接 和 null 合并 无处不在），并使其成为新的 MINOR 版本。

但是我的一些用户抱怨并要求我将其更改为新的主要版本。 同样之前，当我在 MINOR 版本上强制执行 Node.js v10 时，没有人抱怨。

我找不到任何关于此事的资源，即使 semver spec 也没有指定这一点（甚至在常见问题部分中也没有）。该规范仅讨论 API。

我想让我的项目符合正确的政策。

解决方法

引用来自 Twitter (@izs) 的 Isaacs，他是 semver npm 包的作者（顺便提一下 npm 的创始人）：

我一直认为 SemVer Major 的意思是“你将不得不改变一些东西才能开始使用这个更新”。

如果以前的版本在平台版本 X 上工作，而新版本需要平台版本 X+n，则符合条件，是的。

,

这也是discussed here in many threads和SemVer discusions。有些人声称这是主观的，但我认为如果你用像 OBV（对象版本化）这样的东西来代替固执己见的术语（API、包、产品），你会看到规范和大多数知识渊博的参与者都同意对方。

如果您的客户的构建环境因您发布次要版本或补丁版本而损坏，他们有权投诉。 SemVer spec 确实更侧重于 API 版本控制，而不是包，尽管它确实在一些地方提到了后者。所以这里的关键是，我们中的大多数人实际上从来没有只对 API 进行版本控制，我们对包和其中的清单进行版本控制，其中还隐式/显式地包含传递依赖项。

SemVer 的全部意义在于向那些 OBV 的消费者传达风险。作为发布者，您应对包含在 OBV 中的整个依赖关系树负责。您可以选择是隐式还是显式地将破坏性传递依赖项引入您的 OBV，因此您有责任通过碰撞主要版本来告知客户风险。