使用 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 节，下面的 link）："Example: 1.0.0-alpha < 1.0.0"。这表明“1.0.0”的两个版本可以共存。

或者我应该为每个版本增加 minor/patch，例如：

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 为您提供了很大的灵活性。规范中的任何内容都不排除您使用您在原始 post 中描述的编号场景。就 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 支持无穷无尽的 develop/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，它定义了可用版本中用于决定与消费者意图匹配的排序顺序。

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

releasing alpha to beta to production with SemVer

semantic-versioning