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. 如果我创建一个分支（来自发布标记）以便进行错误修复。 在发布这个补丁时，maven发布插件给出了什么数字？它得到什么标签名称？ 关于将更改合并回主干的任何建议？

2. 更改Maven版本号的标准方法是什么？ Major，Minor和build数何时会增加？

任何能够阐明推荐方法的书籍或文档？

Answer 1

来自使用Maven更好地构建的引用 - Mergere Library Press。

第3.6节。解决依赖冲突和使用版本范围：

  

如果我创建一个分支（来自发布标记）以便进行错误修复。在发布这个补丁时，maven发布插件给出了什么数字？它得到什么标签名称？有关将合并更改回主干的任何建议吗？

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

• 如果更改不需要合并回主干（从分支构建版本），请使用1.0.1-1或1.0.1-patch-1。

• 如果需要将更改合并回主干（从主干构建版本），对于重大更改，请使用2.0.0进行微小更改，使用1.1.0进行错误修复，使用1.0.2。

  

更改Maven版本号的标准方法是什么？什么时候Major，Minor和build数字会增加？

见上图。

更新

  

是的，这是maven版本控制的另一个令人困惑的部分。对我来说，该图与其下面写的内容相矛盾：它表明在发布补丁后，内部版本号会增加。但我认为这就是Bug修复部分版本字符串的原因，如图??

所示

maven版本范围的目的是涵盖尽可能多的用例。您打算如何使用它完全取决于您。这里的重点是哪一个更合理。正如我在原帖中所述，它用于某些特殊情况，例如你的团队需要同时维护两个工作流（主干上的主要工作流和分支上的第二个工作流）。

以这个场景为例，经过长时间的工作，您构建并向客户端部署版本1.0.6（在SVN中，1.0.6被标记，trunk增加到1.0.7-SHAPSHOT，意味着下一个预计发布版本是1.0.7），并在trunk上不断发展。然后两周后，1.0.6版本中报告了一个错误并需要紧急修复，因此您需要从标记1.0.6创建一个分支，修复错误并将分支合并回主干。现在您需要为客户端构建补丁版本。由于trunk从上次构建（两周前）以来已经发生了很大的变化，我们必须从分支构建这个补丁版本。当然，你可以使用任何你喜欢的东西（即1.0.7）来修补这个版本，因此需要手动修改trunk中的版本（从1.0.7-SHAPSHOT到1.0.8-SNAPSHOT）。但是，我更愿意在此补丁版本中使用1.0.6-patch-1。

图中没有任何内容相矛盾，构建编号在这种情况下是完美的，这就是“，而构建编号是发布后的增量，表示修补后的版本。”它为您提供在已发布的版本（1.0.6 - > 1.0.6-patch-1）上增加版本定位的第二次机会，而非准备发布的开发版本（1.0.7-SNAPSHOT - > 1.0.7 ）。

Answer 2

我建议在这种情况下创建一个不同的编号模式。因此，让我们假设我们从1.0.0 Tag创建一个分支，可能命名为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

处理这种情况的默认解决方案是使用release plugin的参数，您也可以使用developmentVersion或releaseVersion。只有在您发布之前知道这一点，这才有效。

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

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

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

Answer 3

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

一般来说，使用major.minor.patch版本控制方案的想法是，修补程序部分会针对错误修复而增加，对于新功能不会破坏向后兼容性，主要 - 向后不兼容的更改和新的主要功能。