Maven/Ivy 版本号和 SVN 主干/git 开发分支答案

【问题标题】：Maven/Ivy version numbers and SVN trunk / git develop branchMaven/Ivy 版本号和 SVN 主干/git 开发分支
【发布时间】：2014-04-18 17:54:54
【问题描述】：

假设以下树：

foo
├──trunk
├──branches
│   ├──1.0-rc1
│   ├──2.0
│   └──2.0-crazy-feature
└──tags
    ├──1.0-rc1
    └──1.0-final

每个目录中的工件应该有什么 Maven/Ivy 版本号？ -- 实际上，我可以猜到分支和标签，但trunk 让我很难过。

foo
├──trunk                  ⇐ ????
├──branches
│   ├──1.0                ⇐ 1.0-SNAPSHOT
│   ├──2.0                ⇐ 2.0-SNAPSHOT
│   └──2.0-crazy-feature  ⇐ 2.0-crazy-feature
└──tags
    ├──1.0-rc1            ⇐ 1.0-rc1
    └──1.0-final          ⇐ 1.0

Maven 约定与这里的 Subversion 约定并不完全匹配，特别是如果您试图严格（参见 Vincent Driessen 的git branching model），不要只通过合并将代码直接检查到主干中。

野外抽查表明大多数人没有那么严格，主干（或 git master）刚开始是 1.0-SNAPSHOT，后来变成 2.0-SNAPSHOT，等等。但假设你的发布计划很复杂足以使您需要将主干与版本发布分支区分开来，并且您不希望构建系统混淆trunk 或branches/2.0 是否是“真正的” 2.0-SNAPSHOT，应该使用什么版本号@ 987654327@生产？

注意我们暂时在这里使用 SVN，但我不希望我们现在做出决定，一旦我们首先让每个人都对适当的分支和适当的版本化工件。此外，上面的树只是一个项目，但我们实际上拥有的是（字面意思）大约 500 个单独的模块，目前在一个单一的单体存储库中。

【问题讨论】：

标签： maven versioning ivy branching-and-merging

【解决方案1】：

这取决于你的后备箱代表什么。

如果您使用 unstable trunk 方法，您的主干版本将是您未来的版本。例如，如果您的上一个版本是 4.9，那么您的主干将是 4.10 或者可能是 5.0，具体取决于您计划在 4.9 之后的下一个版本中调用什么。

Maven 和 Ivy 有不同的方式来引用初步修订。在 Maven 中，初步修订是 SNAPSHOT 修订。他们有自己的存储库。使用 SNAPSHOTS，即使用户有以前的 SNAPSHOT 修订版，Maven 也会自动下载最新版本。当 jar 在 Release repo 中时，如果用户使用的是旧版本，Maven 不会自动下载新版本。

Maven 将与您的版本控制系统集成，并自动更新pom.xml 以将版本更改为非快照编号。

我不是那个的忠实粉丝。我们测试特定的 Subversion 版本。他们经历了一系列的考验。首先，Dev 将进行测试。当他们满意时，他们会将 Subversion 修订版传递给 QA。 QA 测试，当他们满意时，他们会将修订版发送给 UAT。当 UAT 高兴时，我希望那个特定的版本成为我的正式版本，并且我想标记那个。在 Maven 中，我假设让 Maven 进行结帐，更新我的 pom.xml，进行新构建，将新的完全未经测试的 jar 部署为我的正式版本，然后标记我的版本。

在 Ivy 中，jar 在ivy.xml 文件中有一个与之关联的状态：

集成：由连续构建、夜间构建等构建的修订属于此类
里程碑：已向公众发布但尚未真正完成的修订属于此类
发布：经过全面测试和标记的修订版属于此类

其实我更喜欢这种方式。我不必更改修订版。我不需要用于快照等的第二个存储库。它干净简单。不幸的是，它与 Maven 的方法不兼容。我无法想象 Git 和 Subversion 的不同之处在于 Maven 的工作方式。在任一系统中，您都必须使用新的非快照 pom.xml 创建新修订。在以太系统中，您必须重建 jar。在任一系统中，您都必须让 Maven 处理标记。

我们执行以下操作：

我们使用 Jenkins 作为我们的 CI 系统。
出于历史原因，我们的大多数项目都使用 Ivy 而不是 Maven。
当我构建一个 jar 时，我从 ivy.xml 创建了两个 POM。我创建了一个pom-snapshot.xml 和一个pom.xml。我定义了一个特殊的<jar.macro> 任务，它几乎100% 兼容普通的<jar> 任务。除了这个任务会生成一个pom.xml、一个pom-snapshot.xml 和其中嵌入了 Maven 信息的 jar。
我们使用带有两个已定义促销的 Jenkins 升级构建插件。使用pom-snapshot.xml 将jar 部署到Maven 快照存储库。另一个使用pom.xml 将jar 部署到Maven 发布存储库。开发人员将 jar 推广到快照存储库（某些项目会在每次构建时自动执行此操作）。当我们有一个实际的可发布 jar 时，我们将该 jar 提升到 Maven 发布存储库。它还会将该特定构建标记为实际版本。

这意味着我们的分支会同时执行 jar 的快照和发布版本。我们可以选择哪个 Subversion 版本（实际上是 Jenkins 构建的）是我们的正式发布版本。

【讨论】：

【解决方案2】：

根据对Apache projects' 修订历史的随意检查，看起来主干中的版本号应该是比任何分支/标签的最高版本“大一”的快照。

例如，Maven release plugin 用于准备 Camel 项目的 2.11.0 版本，如下所示：在修订版 1468763 中，Camel 项目的主干版本从“2.11-SNAPSHOT”更改为“2.11. 0”。下一个版本将主干复制到新的“2.11.0”标签。随后的修订版将主干版本更新为“2.12-SNAPSHOT”。

【讨论】：