POM的最佳发布策略

时间:2018-06-12 13:46:36

标签: git maven pom.xml release

我正在一个拥有大量独立maven模型的项目中工作,所有这些模型都包含应用程序。 当他们对任何模块进行更改并准备好将其发布到Production时,他们会将所有其他poms更新为pom的新工件版本。 我认为这是整个应用程序的里程碑,即如果需要运行项目的过去版本,他们只需从存储库中选择特定版本号的所有模块。

我在考虑是否可能存在另一种策略,主要是基于我们正在更新模块的pom,而这些模块根本没有改变。

如果存在替代“更好”的策略,请建议利弊。

由于

1 个答案:

答案 0 :(得分:0)

很难明确选项,因为我们对您的项目了解不多。看起来这样或那样,依赖版本规范是这里的一个关键概念。

在一个简单的例子中,如果我有使用模块B的模块A,并且我修改模块B,我可能必须修改模块A以更新其依赖性信息。因为可以使用版本范围指定依赖关系,所以这不一定是真的;特别是如果您正在使用类似真正的REST架构之类的东西来隔离一个模块与另一个模块的更改。

但无论是否属于这种情况,听起来你都说至少有时你的团队更新模块上的版本号而不改变任何依赖信息。在一个极端的例子中,也许每个模块只提供具有严格标准化接口的服务;或许某些其他应用程序使用这些模块,但它们并没有相互使用;或...

在这种情况下,我想问的问题是更改版本号的成本(进行更改的文字成本加上版本号可能传达的任何语义值)是否超过了团队在同步时可能发现的简单性版本号。

就个人而言,我会让版本号独立,并使用&#34;顶级&#34; POM知道每个模块的哪些版本协同工作以形成整个应用程序的版本X&#34;。此顶级POM应使用特定版本号而不是范围,以确保可重现的构建结果。然后,您修改您修改的任何模块,并修改其直接相关性信息受影响的任何模块(因为它可能需要重建),并修改顶级POM,以及所有模块。< / p>

但这只是我的看法,它只涵盖了一些常见的场景。这实际上是团队必须根据具体项目的知识来确定的。