Maven 大项目：一个版本的所有或自己的发布周期为每个子项目？

假设我们有一组Maven工件，它们之间有一些依赖关系。工件由不同的团队拥有，并且可能同时由多个团队拥有。这是我们的大项目。例如：

projectX --- projectA

        |     \
   projectB   projectC 

一个问题是：将所有子项目保留在一个具有一个版本的大型Maven项目中，还是让每个团队拥有自己的工件、自己的发布周期和自己的版本更好？

分离团队的好处很简单：如果一些团队构建失败，其他团队仍然使用该团队提供的旧依赖项，并且没有遇到任何问题。此外，在每个全球版本中，我们都可以看到哪些模块发生了更改，并且更容易发现问题

将团队分开的缺点是：

A队改变了projectX。现在所有的团队都必须重新发布他们的模块

projectX的版本硬编码在3个模块中，这是一个非常容易出错的解决方案。否则，该版本可能会被描述为最新版本或在父模块中硬编码，但如果projectX发生更改，谁会强迫团队重新编译其模块

---

那么，对于这种典型情况，什么是最佳实践呢？

遗憾的是，没有黄金法则。我曾参与过一个大项目（~90个maven模块/子模块……从maven1迁移到maven2！），在那些日子里，我们在开发快照版本时，对每个版本都使用一个大版本

但在我看来，这取决于两个因素：

发布周期需要

打破接口责任

这实际上是管理开发团队的问题，maven的工件版本策略必须遵循管理指南，而不是驱动它（我们必须始终负责我们的工具！）

发布周期需要 如果一个项目/模块需要独立发布，那么强迫其他在其他模块上工作的人做一些事情是不好的。 可以用于允许其他项目依赖刚刚发布的工件

打破接口责任 当我的模块中的更改破坏了另一个团队负责的接口时，会发生什么情况？（或者导致测试失败，因为您有集成测试，对吧？！）

我能换电话号码吗？我是否可以更改其他模块依赖项以明确警告当前版本不再兼容

回答这些问题有助于定义合适的版本策略