maven parent pom with different child versions

Question

There are multiple modules in our applications and each of them have their separate version and depend on other modules(external to our organization). They all have a parent POM which has it's own version, independent from the children's version.

When one of those modules change, they're converted to snapshots.

For the following example:

Parent v14.0
- module1 v1.5.0
    - dependency1(module2 v15.0.0)
    - dependency2(external-jar v12.0.1)
- module2 v15.0.0
- module3 v3.1.0

If there would be a change in module2, then module2's version would become v15.0-SNAPSHOT, then module1 becomes v1.5-SNAPSHOT. The parent remains the same. The purpose for not having the same version on parent+modules, is that we want to localize the updates made to some modules and not affect the others' versions.

This has been designed like this a long time ago and there are several bash scripts to support the updates, although they're not handling all the cases. In any case, we don't have a one-click release process and we feel we are quite far from it with this approach.

We don't know how to convince the management towards a single version approach on all modules. How do you feel about the above? Did you ever encountered a project using the above structure and how well did it go?

Thank you!

Answer 1

I've had to deal with such situations before. There is an actual benefit from having decentralized versions, especially in cases where your product is made out of a large number of modules and this is because of the following facts:

• You don't have to release all of them as a whole, if only a handful have been changed (which, from my observation is almost always the case).

• You don't have to create unnecessary tags in your version control for code which hasn't changed since the previous release.

• You don't have to waste an excessive amount of time releasing modules which don't need to be released.

• You know with certainty which modules have changed in a release, which helps a lot when you need to investigate a complex bug, which seems to be dating back a while.

• You can actually release certain modules/aggregators before the actual release date of the complete product, allowing for more testing time and a feeling of completeness for a given part of the product.

• You can make feature branch releases much easier and implement a continuous delivery in a better way.

• You can re-use the same code across multiple development branches without wondering if that branched version matches the one for your branch (or at least with less confusion).

What we ended up doing was:

• Extract a parent or set of parents (with no sub-modules).

• Try to use fixed versions for parents as much as possible. This is a bit of a caveat, as you must change all modules that inherit it, but in the end it improves the stability.

• Extract each of the modules whose versions are independent of the rest to separate modules.

• Extract sets of modules whose versions must always move along together into aggregators.

• Create jobs in your CI server that can do releases or manually release these modules.

• Use the versions-maven-plugin.

I think it's a lot more mature of a project and company's development principles to use decentralized versions and I must admit that in the beginning I was very reluctant to this approach. You might not realize or understand the benefits immediately, but with some practice and a proper setup, you will start seeing the upsides. I'm not saying there aren't caveats like... for example bumping the version of a parent, or having to know in which modules to bump the version of one of your modules.

From my experience, this module actually works better in the end, once you've become used to working with it.