semantic-versioning - SemVer 中 MINOR 与 PATCH 规则的原因

Question

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

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

以下是 SemVer 规则供引用:

进行不兼容的 API 更改时的主要版本，

以向后兼容的方式添加功能时的次要版本，以及

进行向后兼容的错误修复时的补丁版本。

所以 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

该标准刻意简洁。没有什么可以阻止您发布一堆错误修复以及您的新功能，您只需在执行此操作时碰撞次要字段。如果更改仅涉及错误修复、重构或不添加、删除或修改任何接口(interface)的文档，那么您只需修改补丁即可。重点是与您的消费者沟通，了解他们在从您那里获取更新时的风险程度。

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