我们的应用程序中有多个模块，每个模块都有各自的版本，并依赖于其他模块（我们组织外部）。他们都有一个父POM，它有自己的版本，独立于孩子们的版本。
当其中一个模块发生变化时，它们会转换为快照。
对于以下示例：
Parent v14.0
- module1 v1.5.0
- dependency1(module2 v15.0.0)
- dependency2(external-jar v12.0.1)
- module2 v15.0.0
- module3 v3.1.0
如果module2有变化，那么module2的版本将变为v15.0-SNAPSHOT，然后module1变为v1.5-SNAPSHOT。父母保持不变。 在父+模块上没有相同版本的目的是，我们希望本地化对某些模块所做的更新，而不是影响其他模块。版本
很久以前就已经设计好这个了，并且有几个bash脚本来支持更新，尽管他们并没有处理所有的情况。无论如何，我们没有一键式发布过程，我们觉得这种方法离它很远。
我们不知道如何说服管理层在所有模块上采用单一版本方法。你觉得上面怎么样？您是否遇到过使用上述结构的项目以及它的效果如何？
谢谢！
答案 0 :(得分：6)
我以前不得不处理这种情况。分散版本有一个实际的好处，特别是在您的产品由大量模块制造的情况下，这是由于以下事实：
如果只改变了一小部分，那么你不必全部释放它们（根据我的观察，几乎总是如此）。
您不必在版本控制中为自上次发布以来未发生变化的代码创建不必要的标记。
您不必浪费太多时间释放不需要释放的模块。
您肯定知道某个版本中的哪些模块发生了变化，这在您需要调查复杂错误时会有很大帮助，这个错误似乎可以追溯到一段时间。
您可以在整个产品的实际发布日期之前实际发布某些模块/聚合器，从而为产品的特定部分提供更多的测试时间和完整感。
您可以更轻松地制作功能分支版本，并以更好的方式实现持续投放。
您可以在多个开发分支中重复使用相同的代码，而不会想知道该分支版本是否与您的分支版本匹配（或至少具有较少的混淆）。
我们最终做的是：
提取父母或一组父母（没有子模块）。
尝试尽可能为父母使用固定版本。这有点需要注意，因为您必须更改继承它的所有模块，但最终它会提高稳定性。
将每个版本独立于其余模块的模块提取到单独的模块中。
提取模块集，其版本必须始终一起移动到聚合器中。
在CI服务器中创建可以执行发布或手动释放这些模块的作业。
我认为使用分散版本的项目和公司的开发原则更为成熟，我必须承认，在开始时我对这种方法非常不情愿。您可能没有立即意识到或理解这些好处，但通过一些练习和正确的设置，您将开始看到好处。我并不是说没有类似的例子......例如碰撞父母的版本，或者不得不知道哪些模块会碰到你的某个模块的版本。
根据我的经验，一旦你习惯了这个模块，这个模块实际上效果会更好。
答案 1 :(得分：1)
根据我的经验：我们尝试过的每个地方，最终都失败了。
尽管Maven支持这种方法，但由于额外的努力，这是不可取的。
在选择是使用不同项目还是多模块结构时，我尝试使用以下标准：
要做到这一点，不同的结果是自制的解决方案既不能很好地扩展，也不易维护。
希望有所帮助。