Continuous Integration Assemblies - Versions

Question

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

So far, in our assemblies, we have used RELEASE as the version for all components in each assembly.

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

This has the advantage that we always use the latest version of each dependency, but has a major drawback: our assemblies are not playable because you do not know which dependencies should have been used in the past (because the versions say that RELEASE is not 1.3.2, for example )

If we move on to using fixed release numbers, we get reproducible builds, but won't we lose the Continuous Integration advantage of telling us what is broken now? Isn't that the point of continuous integration?

What is the standard way to do this?

Regards, D

Answer 1

First of all, plan to stop using RELEASE . no longer supported in Maven 3 for plugin versions; the links to it seem to have been removed from Maven's online books, and I would expect it to become obsolete for dependency versions, after all, if it hasn't been (I can't find authoritative information anyway). Browse / request the user mailing list for confirmation if you are unsure. You have already diligently studied the reproducibility of the assembly.

Secondly, I agree with the answer that you usually want to define fixed versions of the dependencies of your projects, unless you make changes to several projects at the same time, in which case you need the SNAPSHOT dependency version. But this should only be until they are ready for release. At this point, you should release the lowest level, switch the dependency qualifiers to the new fixed version in other projects, and repeat for each project until completion. You should only release a new version of the project if all the dependencies are fixed versions. release plugin can help with this.

Thirdly, it can be very useful or interesting to know if the current "tips" of several projects work, even if they are in independent release schedules! Planning compatibility backward or forward, right? With more projects, this is becoming more important. I think this is the "continuous integration" that you are talking about (although today CI usually refers to the constant building and testing of changes from several developers working on the same branch).

In this case, you must create a top-level aggregator project that defines all related projects as modules. You can do this in the workspace without making changes to version control, or you can create a branch for specific integration for each project that tracks changes to the main line. In any case, you will need to use versions : use the latest version of the target to automate updates for POM or use version ranges so that maven chooses the same way you currently use RELEASE (although I prefer the version to be as explicit as possible).

(Strictly speaking, you do not need a top-level aggregator, but otherwise you will have to do this with each project independently, when you are really interested in how they work together.)

Answer 2

If we switch to using the fixed version of the numbers, we get reproducible assemblies, but we do not lose the advantage. Continuous integration tells us what is now broken? Isn't that the point of continuous integration?

No I do not agree. Each referenced project must have its own CI assembly and should report what is broken.

If your CI project is project a and is dependent on project b, then assembly a should verify the validity of project a, not b. So, the only thing that is interesting for Build a is that Project a works with the specified version of Project b. (The fact that the latest version of project b doesn't matter)

Answer 3

There are several possible solutions to your problem, the most common of which are:

1) You could combine several projects together, if all of them should build and form a dependency tree in any case, into a single set of modules. It uses maven

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

which is concise and useful when grouping projects that need to be mapped together as a group. Then you need a script that updates the version numbers of all the pom.xml files for children to the correct version when you release (or, much less preferred, use the maven-release plugin). Thus, each part of the project is moved and matched together as a whole; you can start adding real revision numbers (i.e. 1.3.2).

2) If you cannot map common subprojects into a cohesive solution with modules, the next best option is to use SNAPSHOTS. By installing the version in the dependency project on something like:

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

You get the opportunity to navigate in separate base codes immediately. Your main project can track changes in the library, being directly dependent on the snapshot:

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

or you can depend on an older version to continue the current development cycle (i.e. using 1.3.1) and then update the dependency after version 1.3.2 has been released.

This option is a bit more complicated when tracking several independent projects, but it remains clear that it depends on which version, clearly in the source. This is a drawback compared to versions of modules together. On the other hand, do most CI systems (including Hudson) have a checkbox at the end of the configuration section for a job that asks for "Build dependent projects"? (or something like that). When you test and run as a maven build, whenever your SNAPSHOT-A ​​dependency performs a rebuild, Hudson can automatically run the build of any project that depends on the -A dependency. This can be very convenient if you have a common, constantly updated dependency.