SemVer 中 MINOR vs PATCH 规则的原因

Question

何时使用SemVer 2.0增加 MAJOR 与 MINOR 版本号的规则非常引人注目。它们显然为了解应用程序/服务是否向后兼容提供了很多优势。

但是该站点并没有真正说明 MINOR 和它所谓的 PATCH 之间的差异的原因。我不认为它具有 MAJOR 与 MINOR 相同的好处。

以下是 SemVer 规则供参考：

1. 进行不兼容的 API 更改时的主要版本，
2. 以向后兼容的方式添加功能时的 MINOR 版本，以及
3. PATCH 版本，当您进行向后兼容的错误修复时。

因此 MINOR 和 PATCH 之间的唯一区别是功能与错误修复。我的公司希望以不同的方式做到这一点。

他们希望 MINOR 成为 [向后兼容] 功能的集合。“补丁”（我们称之为增量）是发布这些功能所需的版本。（我们在发布功能时发布错误修复。）

例如，如果我们计划在 2.4 版本中提供 7 个[向后兼容]功能，那么 2.4.0 可能有 2 个功能，2.4.1 将有 3 个功能，2.4.2 将有最后 2 个（可能有一个错误在每个版本中修复或两个）。

我可以看到这违反了 SemVer，但我需要知道为什么 SemVer 决定对 MINOR 和 PATCH 版本之间的差异进行说明，以便我知道用哪种方式推动我的公司。

注意：我希望这对于 Stack Overflow 来说不是太主观。我通常不会问这样的问题，所以这个问题可能需要关闭......

Answer 1

标准是故意简洁的。没有任何内容可以阻止您发布一堆错误修复以及您的新功能，并且您只需在执行此操作时触及次要领域。如果更改仅涉及错误修复、重构或不添加、删除或修改任何接口的文档，那么您只会打补丁。重点是向您的消费者传达他们在从您那里获取更新时的风险水平。

编辑：最佳做法是将错误修复（补丁）与功能工作（次要）和重大更改（主要）分离到单独的版本中。这允许您的消费者自动获取最新的修复程序，而无需处理功能膨胀或破坏性更改。