通过SemVer增加版本可能是一个品味的问题，但肯定它有它的边界，我无法通过研究找到。我想到了一种方法来增加我的版本，这取决于自上一个标签以来的git提交历史。请核实我的陈述或向我提供替代方案。
v0.0.1 (v0.1.0) (v0.1.1) v0.1.1
master o--o--------------------------------o----->
release \______________________________/
| | | |
F M M F
1 1 2 2
提交历史记录包含两个修正（F）和两个小修改（M）。 第二次次要更改（M2）之前的所有内容都被视为次要更改，因为之前没有任何更高的更改，例如突破性更改（B）。
以下是我为次要版本添加+1的地方： v.0.1.0
然而在最后一次更改（M2）之后存在修正更改（F2）。根据最后的微小变化（v0.1.0），这个被视为补丁更改。
因此，此修补程序更改会将修补程序版本增加1： v0.1.1
v0.0.1 (v1.0.0) (v1.1.0) (v1.1.1) v1.1.1
master o--o------------------------------------------o----->
release \________________________________________/
| | | | |
F B M M F
1 1 1 2 2
另一个例子，其中突破性变化（B1）作为最高版本占主导地位。但是，所有后续版本仍然依赖于该突破性更改，并且由于其版本的语义值而允许递增。
首先，主要变化将增加到 v1.0.0 ，并将两个微小变化（M1和M2）分组为一个小的变化增量将导致 v1.1.0 。最后，根据微小变化（M1和M2）或主要/突破变化（B1），仍然存在修复/补丁变化。这会将补丁版本增加1到最终： v1.1.1
v0.0.1 (v0.1.0) v0.1.0
master o--o--------------------------------o----->
release \______________________________/
| | | |
F M M F
1 1 2 2
在这种情况下，只有最高的更改才会被视为影响版本号的那个，无论更改的时间顺序如何。
最高变化是次要变化（M1 | M2），因此版本将增加1： v0.1.0 如果修复（F2）之后在语义上依赖于最后的微小变化（M2），即使它可能修补/修复了由最后一次微小变化（M2）添加的特征，也无关紧要
v0.0.1 (v1.0.0) v1.0.0
master o--o-------------------------------o----->
release \_____________________________/
| | | | |
F B M M F
1 1 1 2 2
另一个例子，其中突破性变化（B1）将主导所有其他版本，因为它是最高/最相关的变化。
是否有关于如何根据更改类型增加版本的最佳做法？两种方式都有效，或者其中一种方式是 SemVer 的惯例吗？
答案 0 :(得分：1)
所以你基本上都在询问是否可以接受在较高场凸起中消除不太重要的场？虽然在主要碰撞之前或之后有很多次要和补丁级别的变化，但是在0.0.x到1.0.0之间？答案是肯定的，这是可以接受的。 SemVer引用了版本或预发行版，它没有引用对代码所做的每一点改动。算法非常简单：
这有助于减少公开可见版本序列中的间隙数量，并允许探险者发现已从公共Feed中删除的版本。在实践中，这样的馈送无论如何都充满了空白，因为我们通常以某种形式对几乎所有CI构建进行飞行测试，因此我们沿途浏览大部分可用的版本号，并且只在馈送中留下最重要的里程碑。
如果您需要进一步澄清，请询问，我们很乐意尝试回答任何问题。