api - semver 中补丁号递增的规则

Question

根据semver

"PATCH version when you make backwards-compatible bug fixes."

和

"A bug fix is defined as an internal change that fixes incorrect behavior."

考虑到这一点，假设我有一个可以调用的变量，例如颜色。由于某种原因，我需要更改颜色值。

v1.0.0
$color: #FFF;

v1.0.1
$color: #F0F0F0;

现在，这是一个在 API 中定义为用户可以调用的变量。我没有更改调用的实际变量，只是更改了它返回的值。为此，我必须在 API 元素上更改我的代码，并且必须将此代码合并到生产分支中。但是这样的事情真的需要增加 API 的补丁版本号吗？

Answer 1

语义 版本控制的要点是管理软件系统的依赖关系。语义版本控制提供了一个有组织的规范来标准化此过程，以便可靠地跟踪这些系统的状态。正如规范所述，

Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

如果您的更改影响 api(输入或输出)的行为并需要发布版本，则该版本应与适当的版本号 Hook 。这将使软件包的用户可以放心地依赖您的软件包。每个版本都会按预期运行；不应有任何歧义。

<小时/>

举个例子，假设您进行了更改并发布了它，但不增加补丁号。您可能有两个用户认为他们使用相同的代码，但在调用 $color api 时获得不同的值，具体取决于他们获取 v1.0.0 的时间。

值得注意的是，根据您发布软件包的方式，可以通过不同的方式向用户提供此更改。我可以想到两种可能的情况:

• 如果软件包源是公开的，则在软件包的早期开发过程中，可以将快速更改推送到开发分支，用户可以在其中自行承担更改的风险。
• 或者，如果软件包不是开源的，则可以通过在版本中附加标识符来进行预发布(请参阅规范中的第 9 项和第 10 项)。

这些只是几个选项。根据您的具体情况，可能还有其他内容。

TL;DR 答案

最重要的是，一旦发布了 v1.0.0，v1.0.0 的行为方式应该始终相同。无论这些变化多么微不足道，它们仍然是变化。这适用于所有版本，X.Y.Z。