使用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 <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.主版本零（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，它定义了可用顺序中的排序顺序，用于根据可用版本确定与消费者意图的匹配。