语义版本控制 (Semver) - 如何对向后兼容的大型功能更新进行 semver

Posted 2023-03-07

【中文标题】语义版本控制 (Semver) - 如何对向后兼容的大型功能更新进行 semver

【英文标题】：Semantic Versioning (Semver) - How to semver large functional updates that are backwards compatible

【发布时间】：2019-09-03 16:00:25

【问题描述】：

我的理解是，使用 X.Y.Z，我们只更改 X 以进行重大更改。 Y 用于向后兼容的功能更改。

所以我是否正确地假设即使我的更新是对功能的绝对巨大的补充——没有重大变化，因为它只是一个补充，我仍然不会改变 X。

TLDR无论更新多么“重大”，如果不是重大更改，您都不会更改 X.Y.Z 的 X

【问题讨论】：

所有主要更新，包括添加 NEW API 都应该改变 X。它并没有说它必须改变 X，但是你期望如果 node.js 添加新的 API 它会改变它的版本号，而不仅仅是点号.重大更改必须更改 X，但这并不意味着您不能出于任何其他原因更改 X（即使是庆祝生日这样的微不足道的原因）

【参考方案1】：

您可以为向后兼容的大型功能更新增加主要版本号。我认为你通常应该这样做。

Semver 2.0.0 的第 8 段指出：

如果将任何向后不兼容的更改引入公共 API，则必须增加主版本 X (X.y.z | X > 0)。 可能包括次要和补丁级别更改。当主要版本增加时，补丁和次要版本必须重置为 0。 （已添加重点。）

严格应用 RFC 2119 术语 MAY、MUST 和 MUST NOT 以引用方式并入 Semver，强调的声明意味着当更改仅包括次要版本时，允许但不要求增加主要版本号和补丁级别的变化。

这就是大量非破坏性更改的含义：大量次要和补丁级别的更改。

在规范的这一段中明显没有任何声明等同于：

不得仅包括次要和补丁级别的更改 它必须包含向后不兼容的更改

根据第 7 段，另一种允许的替代方法是仅在您的场景中增加次要版本。

这很好。在您描述的公共 API 在技术上没有以向后不兼容的方式更改但更改足够大以至于 感觉 像对 (可能是人类）用户和/或开发人员。

它还允许有时业务/营销驱动的需要根据重要的功能更改而不是 API 规范本身来增加主要版本号。