Home/ Questions/Q 3750948
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T09:00:17+00:00

I had a question regarding the use of version numbers, RELEASE versions and continuous

  • 0

I had a question regarding the use of version numbers, RELEASE versions and continuous integration.

So far in our builds we have been using RELEASE as the version for all the components in every build. 

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

This has the advantage that we always use the most up to date release of every dependency but has the major drawback that our builds are not reproducible as you don’t know what dependencies were supposed to be used at a point in the past (as the versions says RELEASE not 1.3.2 for example).

If we switch to using fixed release numbers, we get reproducible builds, but don’t we lose the advantage of Continuous Integration telling us what has now broken? Isn’t this the point of Continuous Integration?

What is the standard way of doing this?

Regards,
D

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First of all, plan to stop using RELEASE. It is no longer supported in Maven 3 for plugin versions; it appears that references to it have been removed from the online books about Maven and I would expect it to be deprecated for dependency versions eventually if it isn’t already (I can’t find authoritative information one way or the other). Review/ask the users mailing list for confirmation if you are unsure about this. You’ve already learned the hard way about build reproducibility.

    Second, I agree with the answer that you will generally want to define fixed versions for your projects’ dependencies, unless you are making changes to multiple projects at once, in which case you want a SNAPSHOT dependency version. But this should only be until they are ready to be released. At that point, you should release the lowest-level one, switch the dependency specifiers to the new fixed version in the other projects, and repeat for each project until done. You should only release a new version of a project if all of the dependencies are fixed versions. The release plugin can help with this.

    Third, it can still be very useful or interesting to know if the current “tip” of multiple projects work together, even if they are on independent release schedules! Backward/forward compatibility planning, right? With more projects this becomes more important. I think this is the “continuous integration” you are talking about (although these days CI usually refers to continuously building and testing the changes from multiple developers working on a single branch).

    In this case you should create a top-level aggregator project that defines all related projects as modules. You can do this in a workspace without committing changes to version control, or you can create an integration-specific branch for each project that tracks the mainline changes. In either case, you will then want to use the versions:use-latest-versions goal to automate the updates to the POMs, or use version ranges to let maven choose similarly to how you currently use ‘RELEASE’ (although I prefer having the version be as explicit as possible).

    (Strictly speaking, you don’t need the top-level aggregator, but otherwise you are having to do this with every project independently, when really you are interested in how they work together.)

    • 0