使用SemVer将alpha发行到beta版本以进行生产

我对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/

该SemVer规范为您提供了很大的灵活性。规范中的任何内容都不能阻止您使用原始帖子中描述的编号方案。就SemVer而言，您的替代建议也有效。两种方案均以0.yz形式开始，该形式应用于最初的开发，直至1.0.0。尽管会影响排序顺序（1.0.0> 0.1.0> 0.1.0-otherPreleaseTag> 0.1.0-anyPreleaseTag），但所有应用的预发行标签大多都是糖。

4.主要版本零（0.yz）用于初始开发。随时可能发生任何变化。公共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. ...预发行版本表示该版本不稳定，可能无法满足其关联的正常版本所表示的预期兼容性要求。

您只需要关注优先级规则，该规则定义了可用顺序中的排序顺序，该顺序用于确定与消费者意图的匹配。