我们的应用程序中有多个模块,每个模块都有各自的版本,并依赖于其他模块(我们组织的外部).他们都有一个父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脚本来支持更新,尽管他们没有处理所有的情况.无论如何,我们没有一键式发布过程,我们觉得这种方法离它很远.
我们不知道如何说服管理层对所有模块采用单一版本方法.你觉得上面怎么样？你有没有遇到过使用上述结构的项目,它有多好？
谢谢!
我以前不得不处理这种情况.分散版本有一个实际的好处,特别是在您的产品由大量模块构成的情况下,这是由于以下事实:
如果只改变了一小部分(从我的观察中几乎总是如此),你不必整体释放它们.
您不必在版本控制中为自上一版本以来未更改的代码创建不必要的标记.
您不必浪费过多的时间来释放不需要释放的模块.
你肯定知道哪个模块在一个版本中发生了变化,当你需要调查一个复杂的bug时,这很有帮助,这个bug似乎可以追溯到一段时间.
实际上,您可以在整个产品的实际发布日期之前发布某些模块/聚合器,从而为产品的给定部分提供更多的测试时间和完整感.
您可以更轻松地进行功能分支发布,并以更好的方式实现持续交付.
您可以在多个开发分支中重复使用相同的代码,而不会想知道该分支版本是否与您的分支版本匹配(或者至少具有较少的混淆).
我们最终做的是:
提取父项或父项集(没有子模块).
尝试尽可能为父母使用固定版本.这有点需要注意,因为您必须更改继承它的所有模块,但最终它会提高稳定性.
将其版本独立于其余模块的每个模块提取到单独的模块.
提取模块集,其版本必须始终一起移动到聚合器中.
在CI服务器中创建可以执行发布或手动释放这些模块的作业.
我认为使用分散版本的项目和公司的开发原则要更加成熟,我必须承认,在开始时我对这种方法非常不情愿.您可能没有立即意识到或理解这些好处,但通过一些练习和正确的设置,您将开始看到好处.我并不是说没有类似的例子......例如碰撞父版本,或者必须知道哪些模块会碰到你的某个模块的版本.
根据我的经验,一旦你习惯了这个模块,这个模块最终会更好地工作.