SVN中的Maven发布周期和版本控制

Question

我正在试图找到一些关于版本号的可靠信息，以及Maven和SVN的分支/合并。

我的项目使用Maven版本规则：

<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])

我的Maven发行版如下所示，其中包含了主干和发布标记中的快照

trunk:    1.0.0-SNAPSHOT

tag:      1.0.0

trunk:    1.0.1-SNAPSHOT

tag:      1.0.1

etc....

问题：

1. 如果我创建一个分支(从一个发布标签)来做一个tag修复。当涉及到发布这个补丁时，maven发布插件会给它多少号？它有什么标签名？有关于将更改合并回主干的建议吗？
2. 更改Maven版本号的标准方法是什么？大调、小调和构建数什么时候会增加？

有什么书或文档可以说明推荐的方法吗？

Answer 1

引用了Better Builds with Maven - Mergere Library Press。

第3.6款。解决依赖关系冲突并使用版本范围：

​

​

如果我创建一个分支(从一个发布标签)来做一个tag修复。当涉及到发布这个补丁时，maven发布插件会给它多少号？它有什么标签名？有关于将更改合并回主干的建议吗？

在执行mvn release:prepare时，您将有机会填充特定的版本名称(发布版本、标记版本、下一个主干版本等等)。如果你不喜欢Maven生成的那个。在某些特殊情况下，例如从分支构建补丁发行版，我们通常自行设置版本号：

• 如果更改不需要合并回主干(从分支构建版本)，则使用1.0.1-1或1.0.1-修补程序1。
• 如果更改需要合并回主干(从主干构建版本)，对于主要的更改，使用2.0.0，对于小的更改，使用1.1.0，用于错误修复，使用1.0.2。

更改Maven版本号的标准方法是什么？大调、小调和构建数什么时候会增加？

见上面的图表。

更新：

是的，这是maven版本控制的另一个令人困惑的部分。对我来说，图与下面写的内容相矛盾:它声明在发布修补程序后，版本号会增加。但我认为这就是版本字符串的Bug部分的用途，如图表所示？？

maven版本范围的目的是覆盖尽可能多的用例。你打算如何使用它完全取决于你自己。这里的重点是哪一个更合理。正如我在最初的文章中指出的，它被用于某些特殊情况，比如您的团队需要同时维护两个工作流程(主干上的主要工作流和分支上的第二个工作流)。

以这个场景为例，经过很长时间的工作后，您构建并将1.0.6版本部署到您的客户端(在SVN中，1.0.6被标记，主干被增加到1.0.7-shap击，这意味着下一个预期的版本是1.0.7)，并且在主干上继续开发。两周后，版本1.0.6中报告了一个bug，需要紧急修复，因此您可以从标记1.0.6创建一个分支，修复错误并将分支合并回主干。现在，您需要为客户端构建一个补丁版本。自从上一次构建(两周前)以来，主干已经发生了很大的变化，所以我们必须从分支构建这个补丁版本。当然，您可以在这个补丁版本中使用任何您喜欢的(即1.0.7)，因此需要手动修改主干中的版本(从1.0.7到1.0.8-快照)。但是，我更愿意在这个补丁版本中使用1.0.6-补丁-1。

图中没有任何矛盾之处，在这个场景中，版本号是完美的，这就是它的意思：“虽然版本号是发布后的一个增量，以指示修补的构建。”它为您提供了第二次机会来增加针对已经发布的版本(1.0.6 -> 1.0.6补丁-1)的版本，而不是准备发布的开发版本(1.0.7-快照-> 1.0.7)。

Answer 2

在这种情况下，我建议创建一个不同的编号方案。因此，让我们假设我们从1.0.0标记创建一个分支，其名称可能类似于1.0.0-BFB。maven工件的版本--我会使用这样的东西：

1.0.0.1-SNAPSHOT 

如果发布此工件，版本号将转到：

1.0.0.1

这是一个可以简单增强的单个更改的解决方案，在1.0.0行上有多个更改，如下所示。从1.0.0标记创建分支，并将其命名为MB-1.0.0，工件的版本如下：

1.0.0.1-SNAPSHOT
1.0.0.1
1.0.0.2-SNAPSHOT
1.0.0.2
1.0.0.3-SNAPSHOT
etc.

默认情况下，Maven中的标记名由artifactId的名称和版本计算。

这样的维护分支的创建可以通过这样的发布插件来完成：

mvn -B -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DreleaseVersion=1.0.1-SNAPSHOT -DbranchName=MB-1.0.0 release:branch

处理这种情况的默认解决方案是为释放插件使用参数，在这里您也可以使用developmentVersion或releaseVersion。只有当您在发布之前知道这一点，这才能起作用。

但通常情况是，您发布了一个版本，并决定稍后更改次要版本或主要版本。因此，您还可以使用发布插件，例如：

mvn org.apache.maven.plugins:maven-release-plugin:2.3.2:update-versions -DdevelopmentVersion=WhatEverVersionYouLike

或者您可以使用版本-maven-plugin更新版本号。

Answer 3

您可以完全控制在发布时提供给您的工件的版本。

通常，对于major.minor.patch版本控制方案，修补程序部件对于bug修复来说是递增的，对于不破坏向后兼容性的新特性、主要的向后不兼容更改和新的主要特性，则是次要的。