3

根据semver

“进行向后兼容的错误修复时的 PATCH 版本。”

和

“错误修复被定义为修复错误行为的内部更改。”

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

v1.0.0
$color: #FFF;

v1.0.1
$color: #F0F0F0;

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

4

1 回答 1

2

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

一旦发布了版本化包，该版本的内容不得修改。任何修改都必须作为新版本发布。

如果您的更改影响了 api 的行为（输入或输出）并需要发布，那么该发布应该与适当的版本号挂钩。这将使包的用户可以放心地依赖您的包。每个版本都会按预期运行；不应该有歧义。

例如，假设您进行了更改并发布它，但不增加补丁编号。您可能有两个用户，他们认为他们使用相同的代码，但在调用$colorapi 时根据他们获取的时间获得不同的值v1.0.0。

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

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

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

TL;DR 答案

最重要的是，一旦v1.0.0被释放，就v1.0.0应该始终以同样的方式行事。不管这些变化多么微不足道，它们仍然是变化。这适用于所有版本，X.Y.Z.

于 2014-02-07T17:55:01.767 回答