Maven 不同分支版本控制的最佳实践 [开发、质量保证/预发布]

我有几个在不同分支上开发和发布的项目，即发展 and release。这个过程运行得很好，但不幸的是它有一些缺点，我一直想知道是否有更好的版本控制方案适用于我的情况。

主要开发发生在开发分支上（即 Subversiontrunk但这并不重要）开发团队在哪里提交更改。构建和打包工件后，Jenkins 将它们部署到 Maven 存储库和开发集成应用程序服务器。这是一个开发快照，基本上只是一个特征分支 http://martinfowler.com/bliki/FeatureBranch.html包含一个公共分支上的所有已开发功能：

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>D.16-SNAPSHOT</version>

当 QA 团队完成并请求一项特定业务变更时，这一单一变更将被合并到发布分支（分支/发布）。 Jenkins 将生成的工件部署到 QA 应用程序服务器：

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>R.16-SNAPSHOT</version>

然后，通过 maven-release-plugin 在软件的发布分支版本上进行发布（它创建一个维护标签/分支以快速修复错误）。 （R.16-快照 => R.16）

开发和发布分支当前版本分别为 D.16-SNAPSHOT 和 R.16-SNAPSHOT。这允许在 Maven 存储库中分离工件，但会产生依赖于标准 Maven 版本控制风格的不同 Maven 机制的问题。这也破坏了 OSGI 版本控制。

现在，您将如何在这样的方案中命名和版本 Maven 工件？有没有更好的办法？除了简单地更改版本控制和命名方案之外，也许我可以对 Maven 结构进行一些更改？但我需要将开发和 QA（发布）SCM 分支分开。

“开发”/“生产”的专家分类器是一个合理的选择吗？

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>16-SNAPSHOT</version>
<classifier>D</classifier>

据我所知，发布工件的常见命名扩展只是工件的名称，没有任何内容，只有指定的版本。开发分支将具有相同的工件名称，但带有快照。

以 twitter4j 为例。发布版本的工件名称是

twitter4j-2.5.5

他们（他的）开发版本的快照

twitter4j-2.6.5-快照

这是几乎每个人都使用的命名约定，并且被大多数工具识别。例如，我的 Nexus 存储库可以指定忽略开发版本的策略，这基本上意味着它会忽略名称中包含 -SNAPSHOT 的工件。

编辑： 对于您的后续问题：

那么，根据您的构建工具，您可以创建具有时间戳或其他唯一标识符的快照。但是，我从未听说过将某些分支逻辑嵌入到工件的名称中，以便连续 int 服务器可以区分它。从工件的角度来看，它要么是一个版本，要么是一个快照，我没有看到将更多逻辑嵌入到工件名称中的好处，只是因为你的 Hudson 允许你这样做。老实说，你的发布周期对我来说似乎不错，但它需要对你的 Maven 工具进行一些微调。如果您不能忍受这一点，我建议您使用分类器而不是依赖名称，因为调整集成服务器总是比许多依赖标准命名约定的插件更容易。总之，我相信您走在正确的道路上。