使用SemVer规范，一个小的破坏性变更是否足以进行主版本升级？

Question

我对SemVer的概念很陌生，它似乎是在我的目前项目中实现的非常有前途的想法。

根据SemVer的概念，如果一个项目名为project-a.b.c，那么a表示主要更新（破坏性更改），b表示次要更新（新实现），c表示补丁更新（错误修复）。

我的问题是，假设我有一个非常小的破坏性更改需要构建和更新我的repo，那么我应该怎么做呢？

这是一个主要更新还是补丁更新？

此外，SemVer只适用于某些软件技术而不适用于所有技术吗？例如，一些Node开发人员告诉我他们很少使用这个。但是，我不确定有多少人正在实践它。

- Thinker-101

Answer 1

Breaking change就是一个破坏性的改变，没有“如果”或“但是”。你应该进行一个重大的更新。

SemVer的目的是传达关于底层代码以及从一个版本到下一个版本发生了什么修改的含义。这个方案适用于任何需要解决兼容性问题的地方，而SemVer约定则非常符合这个目的。

https://semver.org/

- igor

Answer 2

对于一些小的破坏性变更来说，必须增加主版本号可能会显得有些过于严厉（我不确定这是否是一个合理的担忧）。

也许会有一种强烈的诱惑，想要使用弃用发布来规避要求，并在次要版本增加时发布一个破坏性变更，只要提前给出“足够的”通知。但这将违反语义化版本2.0.0规范：

如果对公共API引入了任何不兼容的变更，主版本X（X.y.z | X > 0）必须增加。它还可以包括次要版本和修订版本的更改。当主版本增加时，修订版本和次要版本必须重置为0。

如果遵循了“以便用户能够平稳过渡到新的API”的弃用步骤，主版本升级不必成为负担。

如何处理废弃功能？

废弃现有功能是软件开发的正常部分，通常需要这样做以实现进步。当您废弃公共API的一部分时，应该做两件事：（1）更新您的文档，让用户了解变更，（2）发布一个带有废弃功能的新的小版本。在您在新的主要版本中完全删除功能之前，应该至少有一个包含废弃功能的小版本，以便用户可以平稳过渡到新的API。

---

为了减少歧义，规范依赖于对词语“MUST”的正式定义：

1. MUST 这个词，或者词语“REQUIRED”或“SHALL”，意味着该定义是规范的绝对要求。

- Brent Bradburn