如何对项目进行版本号？

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，如果是这种情况，那么如何版本号恰好在开发过程中也以一定的顺序并行？

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

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

2. 如果我使用sub-module 中的feature[sub-sub-module-x]，而我正在使用second level+ sub-modules 例如0.1.1-alpha，0.1.2，我是否需要执行patch release -alpha 等，

3. 在完成sub-module 例如0.2.0-alpha、0.2.0-RC 等的情况下，我是否需要执行minor release。
4. 所以在集成了所有 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

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

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

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

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

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

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

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

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

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