2

我正在尝试找到一些关于版本号以及与 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 版本号的标准方法是什么？主要、次要和内部版本号何时增加？

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

4

3 回答 3

3

来自Better Builds with 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 版本号的标准方法是什么？主要、次要和内部版本号何时增加？

见上图。

更新：

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

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

以这种情况为例，经过长时间的工作，您构建并部署版本 1.0.6 到您的客户端（在 SVN 中，1.0.6 被标记，trunk 被递增到 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）。

于 2012-07-20T00:06:11.733 回答
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

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

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

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

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

于 2012-07-19T17:42:11.743 回答
0

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

通常，使用major.minor.patch 版本控制方案的想法是，补丁部分为错误修复而增加，次要 - 用于不破坏向后兼容性的新功能，主要 - 向后不兼容的更改和新的主要功能。

于 2012-07-19T17:38:16.120 回答