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版本号的标准方法是什么？ 专业，次要和内部编号何时增加？

是否有任何书籍或文档可以帮助您了解建议的方法？

Answer 1

引用Maven的“更好的构建” -Mergere图书馆出版社。

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版本号的标准方法是什么？ 专业，次要和内部编号何时增加？

参见上图。

更新：

是的，这是Maven版本控制中另一个令人困惑的部分。 对我来说，该图与下面的内容矛盾：它指出发行补丁后版本号会增加。 但是我认为这就是如图所示的版本字符串的Bug修复部分？

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

以这种情况为例，经过长时间的工作，您将发行版本1.0.6部署并部署到客户端（在SVN中，标记了1.0.6，主干增加到1.0.7-SHAPSHOT，这意味着下一个预期的发行版本是1.0.7），并且在主干上不断发展。 然后，两周后，在1.0.6版中报告了一个错误，需要紧急修复，因此您可以从标记1.0.6创建分支，修复该错误并将分支合并回主干。 现在，您需要为客户端构建一个修补程序版本。 自从上次构建（两周前）以来，主干已经进行了很多更改，因此我们必须从分支构建此补丁程序版本。 当然，您可以为该修补程序版本使用任何喜欢的名称（即1.0.7），因此需要手动更改中继中的版本（从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标签创建了一个分支，该分支的名称可能类似于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插件的参数，您也可以在其中使用developmentVersion或releaseVersion。 只有在发布之前知道这一点，这才起作用。

但是通常情况是您发布了一个版本，后来又决定更改次要或主要版本。 因此，您也可以使用release插件：

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

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

Answer 3

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

通常，对于major.minor.patch版本控制方案，其思想是：针对漏洞修复，针对次要的（针对不破坏向后兼容性的新功能），针对次要的（向后不兼容的更改）以及新增的主要功能，对补丁程序部分进行递增。