semantic-versioning - 使用 SemVer 将 alpha 到 beta 发布到生产环境

Question

我对SemVer发布周期的理解如下:

我的第一个版本是 0.1.0-alpha.1

我可能会做一些调整并在 0.1.0-alpha.2 重新发布(根据需要重复)

准备好后，我发布 0.1.0-beta.1

我可能会做一些调整并在 0.1.0-alpha.2 重新发布(根据需要重复)

准备好后，我发布到生产环境:1.0.0

我在整个过程中保持相同的次要版本是否正确？ SemVer 网站对此进行了提示(第 11 节，下面的链接):“示例:1.0.0-alpha < 1.0.0”。这表明“1.0.0”的两个版本可以共存。

或者我应该为每个版本增加次要/补丁，例如:

0.1.0-alpha.1

0.1.1-alpha.1

0.1.2-beta.1

0.2.0-beta.1

1.0.0

如果是这种情况，我不知道如何使用 alpha.x 或 beta.x 增量？

引用:https://semver.org/

Answer 1

SemVer spec给你很大的灵活性。规范中的任何内容都不会阻止您使用您在原始帖子中描述的编号方案。就 SemVer 而言，您的替代建议也是有效的。这两个场景都以 0.y.z 形式开始，这意味着用于直到 1.0.0 的初始开发。任何应用的预发布标签大部分都是糖，尽管它们会影响排序顺序(1.0.0 > 0.1.0 > 0.1.0-otherPreleaseTag > 0.1.0-anyPreleaseTag)。

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

这些都是合法的 SemVer 版本历史:

H1

0.1.0
0.1.1
0.2.0
0.2.1
1.0.0

H2

0.1.0
0.1.1
0.2.0
0.2.1
1.0.0-alpha.1
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-beta.2
1.0.0

H3

0.1.0
0.1.1
0.2.0
0.2.1
1.0.0-alpha
1.0.1-alpha
1.0.2-beta
1.0.3-beta
1.0.3

SemVer 支持无穷无尽的开发/ Release模式。关键是规范对所有预发布标签应用了相同的精确语义。

9. ...A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

您只需要关注 precedence rules ，它定义了在确定与消费者意图匹配时应用的排序顺序，来自可用版本。