Java 如果我想发布alphas、beta和rc'；也是吗？ 背景

在过去的几个月里，我一直在用Maven构建Java项目。我的团队工作在一个（现在已经Mavenized）项目上，这个项目有一个定期的发布周期，当项目包含我们想要的所有特性并进入内部测试阶段时，我们从我们的开发分支（git）分支出来。当缺陷消除后，我们将在验收环境中部署项目，在我们投入生产之前，我们的客户有机会批准产品

到目前为止，我们使用了这个简单的版本控制方案：

• 在开发、测试和验收期间，项目版本号为（例如）

  1.0.0-SNAPSHOT

• 当分支出

  1.0.0-SNAPSHOT

  进行测试时，主分支上的开发版本设置为下一个计划版本（

  1.1.0-SNAPSHOT

  ）
• 最终版本被标记为版本

  1.0.0

分支模型（除去所有特征分支等）如下所示：

                      (release-1.0)
                   ╭─── 1.0.0-SNAPSHOT ── 1.0.0 ──╮
── 1.0.0-SNAPSHOT ─┴─────── 1.1.0-SNAPSHOT ───────┴── 1.1.0-SNAPSHOT ──
  (master)

这是可以的，但在验收期间将Maven快照部署为候选版本有点草率，在内部测试期间，发布Alpha和Beta是很好的，这样就可以在精确的版本上归档（从而复制）bug

现在，版本号在分支模型中可能有点像这样：

                    (release-1.0)
                 ╭─── 1.0.0-rc1-SNAPSHOT ── 1.0.0-rc1 ── 1.0.0-rc2-SNAPSHOT ── 1.0.0-rc2 ── 1.0.0 ──╮
── ???-SNAPSHOT ─┴─────────────────────────── ???-SNAPSHOT ─────────────────────────────────────────┴── ???-SNAPSHOT ──
  (master)

此外，在这些候选版本之前，可能有很多alpha和beta版本，也可能没有

问题: 现在我的问题是，

xxx快照

，用Maven的说法，基本上是指将成为

xxx

的版本。但是，如果我们开始发布候选版本，那么在分支后主分支将成为的即将发布的版本不再是

xxx快照

，因为尽管它在最终发布之前排序

xxx

，但它在

xxx-rc1

（和

xxx-alpha1

）之后

那么，在这个模型中，我的初始开发版本应该是什么呢

---

我提出的一个可能的解决方案是在发布分支分离后，将master上的版本号设置为xxx-alpha1-SNAPSHOT，但我想知道是否有某种惯例或最佳实践我忽略了。

这是您在大多数情况下看到的：

---

最后，我们选择命名项目的第一个快照版本，该版本包含alphas、beta和发行候选版本

version-alpha1-SNAPSHOT

，其中

version

是即将发布的版本

因此，如果我们从master扩展到最终发布的

1.0.0

，那么在master上的下一次提交会将版本设置为

1.1.0-alpha1-SNAPSHOT

。这有点难看，但在我们的例子中是一个合适的解决方案，并且与大多数Java库中的版本命名约定非常接近

对于更简单的项目，我们不使用alpha、beta和release候选者，因此不存在问题

---

hwellmann的答案也是一个很好的方法，如果您使用了很多遵循JBoss版本命名方式的软件包，那么推荐使用它。

很有趣。这将允许我以1.0.0-SNAPSHOT开始一个新的开发周期，因为1.0.0.Alpha1在1.0.0之后被视为一个新版本，但它强制最终版本命名为1.0.0.final，并且与我们使用的大多数依赖项命名其版本的方式不同。我偏爱表示版本号的方法。

1.0.0.Alpha[n]
1.0.0.Beta[n]
1.0.0.CR[n]
1.0.0.Final