Question

背景

在过去的几个月里，我一直在使用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版是很好的，因此可以提交（并因此重现）错误确切的版本。

现在版本号在分支模型中可能看起来像这样：

                    (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-SNAPSHOT，用Maven的说法，基本上意味着将成为xxx 的版本。但是，如果我们开始发布候选版本等，那么即将发布的主分支在分支之后的版本不再是xxx-SNAPSHOT，因为虽然它在最终版本xxx之前排序，但它在{{1}之后出现}（和xxx-rc1）。

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

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

Answer 1

这是您在大多数JBoss projects上看到的内容：

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

Answer 2

最后，我们选择命名具有alphas，beta和候选版本VERSION-alpha1-SNAPSHOT的项目的第一个SNAPSHOT版本，其中VERSION是即将推出的版本。

因此，如果我们从master分支到最终发布1.0.0，则master上的下一次提交会将版本设置为1.1.0-alpha1-SNAPSHOT。这有点难看，但在我们的案例中是一个合适的解决方案，并且与大多数Java库中看到的版本命名约定保持接近。

对于更简单的项目，我们不使用alphas，beta和候选版本，因此不存在问题。

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

如果我想发布alphas，beta和rc，我应该在开发期间在Maven项目中使用哪个版本？

背景

问题

2 个答案: