根据semver
"当你进行向后兼容的错误修复时，补丁版本。">
和
"错误修复被定义为修复错误行为的内部更改。">
考虑到这一点，我们假设我有一个可以调用的变量，比如颜色。出于某种原因，我需要更改颜色值。
v1.0.0
$color: #FFF;
v1.0.1
$color: #F0F0F0;
现在，这是一个在API中定义为用户可以调用的变量。我没有更改被调用的实际变量，只更改了它返回的值。要做到这一点，我必须在API元素上对我的代码进行更改，并且我必须将此代码合并到生产分支中。但是像这样的事情真的需要增加API的补丁版本号吗？
语义版本控制的目的是管理软件系统的依赖关系。语义版本控制提供了一个有组织的规范来标准化这个过程，以便可靠地跟踪这些系统的状态。正如规范所述，
一旦发布了版本化包，就不得修改该版本的内容。任何修改都必须作为新版本发布。
如果您的更改影响了api(输入或输出)的行为，并且需要进行发布，那么该发布应该与适当的版本号挂钩。这将允许软件包的用户对您的软件包充满信心。每个版本都将按预期运行；不应该有歧义。
举个例子，假设您进行了更改并发布了它，但不增加补丁号。可能会有两个用户认为他们使用的是相同的代码，但在调用$colorapi时会得到不同的值，这取决于他们获取v1.0.0的时间。
值得注意的是，根据您发布软件包的方式，有不同的方法可以将此更改带给用户。我能想到两种可能的情况：
- 如果包源是公共的，那么在包的早期开发中，可以将快速更改推送到开发分支，在该分支中，用户可以自担风险获得更改
- 或者，如果包不是开源的，可以通过在版本中添加标识符来进行预发布(请参见规范中的第9项和第10项)
这只是几个选项。根据你的具体情况，可能还会有其他人。
TL；DR回答
最重要的是，一旦发布了v1.0.0，v1.0.0就应该始终以相同的方式运行。不管这些变化多么微不足道，它们仍然是变化。这适用于所有版本，X.Y.Z。