maven-2 - 持续集成构建 - 版本控制

Question

我有一个关于使用版本号、RELEASE 版本和持续集成的问题。

到目前为止，在我们的构建中，我们一直使用 RELEASE 作为每个构建中所有组件的版本。

<dependency>
    <groupId>com.mycompany</groupId>
    <artifactId>mydependency</artifactId>
    <version>RELEASE</version>
</dependency>

这样做的好处是我们总是使用每个依赖项的最新版本，但主要缺点是我们的构建不可重现，因为您不知道过去某个时间点应该使用哪些依赖项(因为例如版本说 RELEASE 不是 1.3.2)。

如果我们改用固定的版本号，我们会得到可重现的构建，但我们不会失去持续集成的优势，告诉我们现在出了什么问题吗？这不是持续集成的重点吗？

这样做的标准方法是什么？

问候，
D

Answer 1

首先，计划停止使用RELEASE .是no longer supported在 Maven 3 中用于插件版本；似乎已经从有关 Maven 的在线书籍中删除了对它的引用，如果它还没有，我希望它最终会被弃用(我无法以一种或另一种方式找到权威信息)。如果您对此不确定，请查看/询问用户邮件列表以进行确认。您已经学会了构建可重复性的艰难方法。

其次，我同意您通常希望为项目的依赖项定义固定版本的答案，除非您同时对多个项目进行更改，在这种情况下您需要一个 SNAPSHOT 依赖项版本。但这应该只在他们准备好被释放之前。此时，您应该发布最低级别的，将依赖说明符切换到其他项目中的新固定版本，并为每个项目重复直到完成。如果所有依赖项都是固定版本，则应仅发布项目的新版本。 release plugin可以帮助解决这个问题。

第三，了解当前多个项目的“提示”是否协同工作仍然非常有用或有趣，即使它们处于独立的发布计划中!向后/向前兼容性规划，对吧？随着更多的项目，这变得更加重要。我认为这就是您所说的“持续集成”(尽管如今 CI 通常指的是持续构建和测试来自多个开发人员在单个分支上工作的更改)。

在这种情况下，您应该创建一个将所有相关项目定义为模块的顶级聚合器项目。您可以在工作区中执行此操作，而无需提交对版本控制的更改，或者您可以为跟踪主线更改的每个项目创建一个特定于集成的分支。无论哪种情况，您都需要使用 versions :use-latest-versions 目标是自动更新 POM，或使用 version ranges让 maven 选择类似于您当前使用 'RELEASE' 的方式(尽管我更喜欢让版本尽可能明确)。

(严格来说，您不需要顶级聚合器，但如果您真的对它们如何协同工作感兴趣，则必须独立处理每个项目。)