2

我有一个maven multi-module项目，其中包含超过 6 个子模块。如果一个 3 人团队并行工作，sub-modules每个任务 2 人，那么如何增加版本号。

而我Major.minor.patch-meta在发布周期中遵循版本编号格式。

Project A
   -- sub-module-assembler 
      pom.xml
   -- sub-module-1
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-2 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-3 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-4 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-5 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-6 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
--pom.xml

增加和减少版本号的确切用法parallel programming，而要通知的关键是sub-modules该项目中的一些完全取决于其他一些sub-module，如果是这种情况，那么如何在开发并行时准确地进行版本号以及某些命令 ？

我不清楚以下内容，但这是正确的版本编号方式

  1. meta release如果修复错误，例如 alpha、beta、gamma 等，我是否需要做这些，

  2. 如果我正在使用例如 0.1.1-alpha、0.1.2-alpha 等，我是否需要在完成 a的patch release情况下执行 afeature[sub-sub-module-x]sub-modulesecond level+ sub-modules

  3. minor release在完成例如 0.2.0-alpha 、 0.2.0-RC 等的情况下，我是否需要做一个sub-module。
  4. 因此，在整合了所有 RC 的 0.2.0-RC + 0.3.0-RC + 0.4.0-RC 等之后，我是否需要做major release1.0.0-RTM 等，

所以理解上述流程有点令人困惑..

有什么方法可以自动化build numbering项目中的内容以保持清晰build release numbers。请提供解决方案。

谢谢

4

1 回答 1

1

我怀疑所有版本控制策略都没有答案。但是让我尝试一些提示，这些提示可能会帮助您选择适合您情况的策略。

该项目看起来相当大。我要做的第一个分组是按责任。是否有仅限于某个开发团队的模块？还是整个事情都保持“一体”？希望你能把它分开一点。一旦了解了模块的职责，就需要定义一些生命周期。发布（或错误修复、补丁）的创建方式和频率是多少？由谁创建？如果每个人都遵循相同的节奏，您可以共享一个版本并发布整个树。但通常在大型项目中并非如此。如果很多人共享一个版本，它还会在开发过程中引入副作用。

如果您不打算一次全部释放整个树，您可能会因此对其进行更多拆分。你仍然可以使用一个通用的父 pom.xml（但是一个带有发布版本的）。

我会在父 pom.xml 中为模块定义一个版本并继承它。所以子模块中没有单独的版本。此外，每个依赖于其他模块的团队都不应该使用 SNAPSHOT 依赖项来为其他团队工作。他们只能使用已发布的版本（BETA 或 RC1）。保持构建的可重复性很重要。例如：“没有快照依赖于您不负责的工件（您可以控制更改的内容和时间）”

至于版本控制本身：毫无疑问，更简单的选择可能会更好。所有元信息可能只会混淆实际状态？

绘制部署管道也可能有用：首先出现什么模块，哪些模块依赖于它等等。一个模块中的更改量定义了版本如何更改（主要、次要、补丁更改）。如果这些更改没有跨模块传播（API 保持稳定，这是您的目标），下一个模块可能只会发布补丁。

如果您还没有发布任何内容，请提前计划。每次迭代通常都是一次 API 更改（因此它实际上是一个主要版本）。这将导致版本 18.0.0 发布（经过 18 次迭代）。所以通常次要版本用于表示迭代，补丁版本表示一些修复以稳定该版本。因此，主要版本的选择更多是从营销方面而不是技术方面。

它还取决于您构建的软件类型（产品、内部解决方案、针对您的环境的一些附加服务）。产品有更清晰的版本控制，它们通常使用 META 部分来指示迭代，并使用 major.minor.patch 编号来指示正在发生的事情。该策略（“指出预期的变化”）也可能对您正在做的事情有所帮助？

所以希望这不会引起比你一开始更多的问题:)

于 2014-05-05T12:03:26.940 回答