“这不是错误，而是功能” – SemVer的问题

根据语义版本控制（SemVer）的规则，版本号vx.xx的每个部分均表示不同的更改类型-这些不同的更改类型主要由它们的向后兼容性定义。

主版本号（序列中的第一个）用于不兼容的API更改。 次要版本号（中间的版本号）是在引入新的向后兼容功能时使用的。 修补程序版本号（最后一个）旨在用于向后兼容的错误修复。

尽管SemVer是非常有用的指南，并且上面的定义听起来很明确，但实际上，您可能会发现为某些代码更改找出SemVer分类有时会很困难。 如果您维护着许多其他项目所依赖的库或框架，有时即使是最琐碎的“错误修复”也可能破坏一小部分用户的向后兼容性-部分原因是功能和错误之间的界线可能会模糊次。

有时，其他开发人员的代码可能取决于您的库/模块中未记录的行为，这些行为看起来像是一个功能，但实际上是一个错误（或者仅仅是选择不当的默认配置）。尽管“这不是错误，这是一个功能”在行业中众所周知，当涉及到更复杂的项目时，逆问题也相对普遍（尽管我们通常不愿承认这些问题）。

我认为应该尽可能严格地遵循SemVer，但是我也很重要的一点是要意识到，在某些情况下，SemVer既是艺术又是科学。 有时，当涉及到版本控制时，您需要利用对项目和生态系统的了解来做出明智的概率决策。

From: https://hackernoon.com/its-not-a-bug-it-s-a-feature-the-problem-with-semver-cb067de7843c