大项目：一个版本供所有人使用，还是每个子项目都有自己的发布周期？

Question

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

projectX --- projectA

        |     \
   projectB   projectC 

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

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

分队的缺点是：

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

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

那么针对这种典型情况的最佳做法是什么？

Answer 1

遗憾的是，这没有黄金法则。我从事过一个大项目（约 90 个 maven 模块/子模块......从 maven1 迁移到 maven2！），在那些日子里，我们为每个版本都使用一个大版本，同时使用 SNAPSHOT 版本进行开发。

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

1. 发布周期需要。
2. 打破接口职责

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

发布周期需求

如果一个项目/模块需要独立发布，强迫其他模块上的其他人做某事是不好的。 Maven versions range dependencies 可用于允许其他项目依赖于刚刚发布的工件。

中断接口责任

如果我的模块中的更改破坏了另一个团队负责的界面，会发生什么？ （或者导致测试失败，因为你有集成测试，对吧？！）

我可以更改呼叫代码吗？我可以更改其他模块依赖以明确警告当前版本不再兼容吗？

回答这些问题恕我直言，有助于定义合适的版本策略。