使用语义化版本控制（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节，下面链接）：“Example: 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/

- user1270496

Answer 1

SemVer规范提供了很大的灵活性。规范中没有排除您在原始帖子中描述的带编号情况的使用。从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

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

标题3

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

您只需要专注于优先级规则，这些规则定义了在确定与消费者意图匹配的可用版本时所应用的排序顺序。

- jwdonahue

---

感谢您详细的回答，既然您确认它是可接受的，我将保持我的原始方案。 - user1270496