Question

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

而我在发布周期中遵循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，如果是那么如何在开发按特定顺序并行的情况下如何准确地编号？

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

如果发生错误修复，我需要meta release，例如alpha，beta，gamma等。
如果patch release中的feature[sub-sub-module-x]已完成，我需要sub-module，而我正在使用second level+ sub-modules例如0.1.1-alpha，0.1.2-alpha等，
在完成minor release例如0.2.0-alpha，0.2.0-RC等的情况下，我是否需要做sub-module。
所以在集成了所有RC的0.2.0-RC + 0.3.0-RC + 0.4.0-RC等后，我需要做major release 1.0.0-RTM等。，

所以理解上面的流程是有点用的..

有没有办法让项目中的build numbering自动化，以便保持清晰build release numbers。请提供解决方案。

由于

Answer 1

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

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

如果您不打算一次性释放完整的树，则可以更多地拆分它。您仍然可以使用公共父pom.xml（但是具有已发布版本的父pom.xml）。

我将为父pom.xml中的模块定义一个版本并继承它。所以子模块中没有单独的版本。此外，依赖于其他模块的每个团队都不应该使用SNAPSHOT依赖关系来处理其他团队。他们可能只使用已发布的版本（无论是BETA还是RC1）。保持构建可重复性非常重要。例如：＆＃34;没有快照依赖于您不负责的工件（您控制哪些更改以及何时更改）＆＃34;

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

可能还有一些用途是绘制一个部署管道：首先是哪个模块，哪个模块依赖于它等等。一个模块中的更改量定义版本更改的方式（主要，次要，修补程序更改）。如果这些更改不会跨模块传播（API保持稳定，这是您的目标），则下一个模块可能只会执行修补程序发布。

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

它还取决于您构建的软件类型（产品，内部解决方案，为您的环境提供的一些额外服务）。产品具有更清晰的版本，它们通常使用META部分来指示迭代，使用major.minor.patch数字来指示发生了什么。那个策略（＆＃34;表明期望发生什么变化＆＃34;）可能对你正在做的事情也有所帮助？

所以希望这并没有引起比你在开始时更多的问题：）

如何为项目编号？

1 个答案: