releasing alpha to beta to production with SemVer

Question

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

1. 我的第一个版本是0.1.0阿尔法。1
2. 我可能会做一些调整，并在0.1.0α2时重新发布(根据需要重复(
3. 准备好后，我释放0.1.0-beta.1
4. 我可能会做一些调整，并在0.1.0α2时重新发布(根据需要重复(
5. 准备好后，我发布到生产中：1.0.0

我始终保持相同的次要版本是正确的吗？SemVer网站暗示了这一点(第11节，下面的链接(："示例：1.0.0-alpha<1.0.0"。这表明"1.0.0"的两个版本可以共存。

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

• 0.1.0α1

• 0.1.1α1

• 0.1.2β1

• 0.2.0-贝塔1

• 1.0.0

如果是这样的话，我不知道如何使用αx或βx增量？

参考编号：https://semver.org/

Answer 1

SemVer规范为您提供了很大的灵活性。规范中没有任何内容阻止您使用您在原始帖子中描述的编号场景。就SemVer而言，您的替代建议也是有效的。这两个场景都是从0.y.z表单开始的，该表单用于1.0.0之前的初始开发。任何应用的预释放标签大多是糖，尽管它们会影响排序顺序(1.0.0>0.1.0>0.1.0-其他预释放标签>0.1.0-anyPreleaseTag(

4.主要版本zero(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…预发布版本表示该版本不稳定，可能无法满足相关正常版本所表示的预期兼容性要求。

您只需要关注优先级规则，这些规则定义了在决定与消费者意图的匹配时应用的排序顺序。