git - 如何根据自上次标记以来的提交历史来增加版本？

Question

通过 SemVer 增加一个版本可能是一个品味问题，但它肯定有它的界限，我无法通过研究找到它。我考虑了一种根据自上一个标记以来的 git 提交历史来增加我的版本的方法。请验证我的陈述或为我提供替代方案。

给出

• last-tag:v0.0.1
• ma​​ster:git历史的master分支
• release: git历史的release分支
• B:重大变更/重大
• M:小改动
• F:修复/补丁

示例#1

     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)。

Here is where I add +1 to the minor version: v.0.1.0

但是在最后一个最高 变化 (M2) 之后，有一个修复变化 (F2)。根据上次的小改动 (v0.1.0)，这个被认为是补丁改动。

Therefore this fix change will increment the patch version by 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) 作为最高版本占据主导地位。然而，所有后续版本仍然依赖于该重大更改，并且由于它们对该版本的语义值(value)而被允许增加。

First the major change will increment to v1.0.0 and grouping both minor changes (M1 & M2) to one minor change increment will result in v1.1.0. In the end there is still a fix/patch change left depending on either the minor changes (M1 & M2) or the major/breaking change (B1). This will increment the patch version by 1 to finally: v1.1.1

示例#2

     v0.0.1         (v0.1.0)             v0.1.0
master  o--o--------------------------------o----->
release     \______________________________/
              |      |  |         |
              F      M  M         F
              1      1  2         2

在这种情况下，无论更改的时间顺序如何，只有最高的更改才会被视为影响版本号的更改。

The highest change is a minor change (M1 | M2) so the version will be incremented by 1: v0.1.0 It does not matter if the fix (F2) afterwards semantically depends on the last minor change (M2) even tho it might have patched/fixed a feature added by the last minor change (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 的惯例？

Answer 1

因此，您实质上是在问是否可以接受在较高场凸 block 中省略不太重要的场？与 0.0.x 到 1.0.0 一样，即使在重大冲击之前或之后进行了许多次要和补丁级别的更改？答案是肯定的，这是可以接受的。 SemVer 引用发布或预发布，它不引用对代码所做的每一个小更改。该算法非常简单:

• 对于每个成功的发布/预发布版本
  • 突出适用的最重要的版本字段。

这有助于减少公开可见的版本序列中的间隙数量，并允许探险者发现已从公共(public)提要中删除的版本。在实践中，这样的提要无论如何都充满了差距，因为我们通常以某种形式对几乎每个 CI 构建进行飞行测试，因此我们会在整个过程中搅动大部分可用的版本号，并且只在提要中留下最重要的里程碑。

如果您需要进一步说明，请询问，我很乐意尝试回答任何问题。