使用SEMVER时，小型破裂的变化是否足以进行主要版本升级？

Question

我对 SemVer 的概念很陌生。在我当前的项目中实施这似乎是一个非常有前途的想法。

根据 SemVer 的概念，如果一个项目名为 project-abc ，那么 a 是主要更新（重大更改），b 是次要更新（较新的实现），c 是补丁更新（错误修复）。

我的问题是，假设我有一个非常小的重大更改，我需要构建和更新我的存储库。那我该怎么办？

这是重大更新还是补丁更新？

另外，SemVer 是否只适用于某些软件技术而不适用于所有技术？例如，一些节点开发人员告诉我他们很少使用这个。但是，我不确定有多少人在练习。

Answer 1

重大变更就是重大变更，没有如果或但是。您应该进行重大更新。

SemVer 的目的是传达底层代码的含义以及从一个版本到下一个版本的修改内容。该方案适用于需要解决任何类型的兼容性问题的所有情况，并且 SemVer 约定符合目的。

https://semver.org/

提出一些问题很有用，可以帮助您确定影响而不是影响偏离 SemVer 约定：

1. 我的交付成果有变化吗？
2. 此更改会破坏任何人的代码吗？
   是的=>重大改变；没有=>继续讨论 MINOR 与 PATCH 的下一个问题。

至于开发人员是否使用 SemVer 约定，您会惊讶地发现大量项目使用它，因为它的实用性和简单性，因此我鼓励您在有意义的地方使用它，例如分布式可交付成果。

Answer 2

不得不增加主要版本可能会对小型打破变化感到笨拙（我不确定这是理性的问题）。

使用 reforcation reprecation 给定“足够”通知，要求并释放次要增量的破坏变化。但这将违反语义版本>语义版本2.0.0规范：

主要版本x（xyz | x＆gt; 0）如果将任何向后不兼容的更改引入公共API，则必须增加。它还可能包括次要和补丁级别的更改。当主要版本增加时，补丁和次要版本必须重置为0。

如果遵循“ ”，那么主要版本的升级不必繁重，以便用户可以平稳过渡到新的API ”。

我应该如何处理折旧功能？

贬低现有功能是软件开发的正常组成部分，通常需要进行前进。当您将部分公共API的部分贬值时，您应该做两件事：（1）更新文档以使用户知道更改，（2）发布了对折旧的新次要版本。在您完全删除新的主要版本中的功能之前，应该至少有一个次要版本包含弃用，以便用户可以平稳过渡到新的API。

---

为了最大程度地减少歧义，规格依赖于a ：

1. 必须这个词，或“必需”或“应”的术语意味着
   定义是规范的绝对要求。