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

Question

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

1. 我的第一个版本将是 0.1.0-alpha.1
2. 我可能会进行一些调整并以 0.1.0-alpha.2 重新发布（根据需要重复）
3. 准备就绪后，我发布 0.1.0-beta.1
4. 我可能会进行一些调整并以 0.1.0-alpha.2 重新发布（根据需要重复）
5. 准备就绪后，我发布到生产环境：1.0.0

我在整个过程中保持相同的次要版本是否正确？ SemVer 网站暗示了这一点（第 11 节，下面的链接）：“示例：1.0.0-alpha

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

• 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. 主要版本零 (0.y.z) 用于初始开发。任何事情都可能随时改变。公共 API 不应该被认为是稳定的。

这些都是合法的 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 支持无穷无尽的开发/发布模式。关键是规范对所有预发布标签应用了相同的语义含义。

9. ...预发布版本表明该版本不稳定，可能无法满足相关正常版本所表示的预期兼容性要求。

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