Question

我对使用版本号，RELEASE版本和持续集成有疑问。

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

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

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

如果我们切换到使用固定版本号码，我们可以获得可重现的构建，但是我们不会失去持续集成的优势，告诉我们现在已经破坏了什么？这不是持续整合的重点吗？

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

此致 d

Answer 1

首先，计划停止使用RELEASE。插件版本在Maven 3中为no longer supported;似乎已经从关于Maven的在线书籍中删除了对它的引用，并且我希望它最终会被弃用于依赖版本，如果它还没有（我无法以某种方式找到权威信息）。如果您对此不确定，请查看/询问用户邮件列表以进行确认。你已经学会了关于构建再现性的艰难方法。

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

第三，知道多个项目的当前“提示”是否一起工作，即使它们处于独立的发布计划中，它仍然是非常有用或有趣的！向后/向前兼容性计划，对吧？随着更多的项目，这变得更加重要。我认为这是您正在谈论的“持续集成”（尽管这些日子CI通常是指不断构建和测试来自在一个分支上工作的多个开发人员的更改）。

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

（严格来说，您不需要顶级聚合器，但是否则您必须独立完成每个项目，当您真正感兴趣的是它们如何协同工作时。）

Answer 2

如果我们切换到使用固定版本数字，我们得到可重现的构建，但是我们不会失去优势持续整合告诉我们什么现在已经坏了？这不是重点持续整合？

不，我不同意。每个被引用的项目都应该拥有自己的CI构建，并且应该报告已经破坏的内容。

如果你的CI项目是项目a并且对项目b有依赖性，那么构建a应该测试项目a的有效性，而不是b。所以构建a唯一有趣的是Project a与指定版本的Project b一起工作。（Project b的最新版本是无关紧要的）

Answer 3

您的问题有几种可以想到的解决方案，其中最常见的是：

1）您可以将多个项目组合在一起，如果它们都必须构建并形成依赖树，则将其组合到一个连贯的模块集中。这使用了maven

<modules>
    <module>submodule-A</module>
    <module>submodule-B</module>
</modules>

格式，这是简洁的，并且在将应该作为一个组一起版本化的项目分组时很有用。然后，您只需要一个脚本，在您执行发布时将所有子pom.xml文件的版本号更新为正确的版本（或者，我不太喜欢的选项，使用maven-release-plugin）。这样，项目的每个部分都会移动并作为一个整体进行版本化;然后，您可以开始添加实际修订号（即1.3.2）。

2）如果你不能将常见的子项目整理成一个带模块的连贯解决方案，那么下一个最佳选择就是使用SNAPSHOTS。通过将依赖项目中的版本设置为：

<project>
    ...
    <artifactId>dependency-A</artifactId>
    <groupId>com.company</groupId>
    <version>1.3.2-SNAPSHOT</version>
    ...
</project>

您可以立即在单独的代码库中移动。您的主项目可以通过直接依赖快照来跟踪库中的更改：

<dependencies>
    ...
    <dependency>
        <artifactId>dependency-A</artifactId>
        <groupId>com.company</groupId>
        <version>1.3.2-SNAPSHOT</version>
    </dependency>
    ...
</dependencies>

或者您可以依赖旧版本来继续当前的开发周期（即使用1.3.1），然后在1.3.2版本发布后更新依赖项。

在跟踪多个独立项目时，这个选项稍微复杂一些，但它确实在源中明确保留了取决于版本的清晰度。与版本化模块相比，这是一个缺点。另一方面，大多数CI系统（包括Hudson）在配置部分的末尾都有一个复选框，用于询问“构建依赖项目？”的作业。（或类似的东西）。当检查并作为maven构建运行时，只要您的SNAPSHOT依赖项A执行重建，Hudson就会自动启动依赖于依赖项A的任何项目的构建。当你有一个共同的，不断更新的依赖时，这可能非常方便。

持续集成构建 - 版本控制

3 个答案: