Maven versioning using git branches

Question

This question is for getting feedback on a suggested versioning system for a multi-module java application built using Maven.

We have developed a multi-jar system (micro-services) with about 15 modules/jars. Some of them (5) are libraries used by the other modules in the system but not outside of the system. The modules are all stored in separate git repositories.

We have released first version and need to get serious with branching/versioning.

Goal : Minimize work needed to be done regarding versioning (updating version numbers, manual merge because of different version information per branch, etc).

How : Modules are identified by module name and git branch name, not by module name and version

We build our own "version-files" saved as resources in each module. These contain build time, git commit-id, branch name, build URL, etc, for the module itself plus included modules. So we have no need for any Maven version number after deployment.

Note : For library modules outside the system we use standard approach both for internally developed and externally developed modules. Ie. strict numbered versioning using Maven dependency system.

The system I'm contemplating is to

1. always use the version number <branch-name>-SNAPSHOT in the pom files, plus configuring Maven to always fetch latest SNAPSHOT version (not only daily as it does by default - ref. What exactly is a Maven Snapshot and why do we need it? ).
2. Use a BOM (ref. Maven BOM [Bill Of Materials] Dependency ) to define dependencies.

The pom file for a module in this system will be similar to:

<project>
 ...
 <version>${revision}</version>

  <dependencies>
    <dependency>
            <groupId>mygroup</groupId>
            <artifactId>bom</artifactId>
            <version>${revision}</version>
            <type>pom</type>
            <scope>import</scope>
    </dependency>
  </dependencies>
 <properties>
   <revision>default_version</revision>
 <properties>
</project>

This version is specified during build by executing mvn using similar to: mvn deploy -Drevision=<branch-name>-SNAPSHOT (ref: https://maven.apache.org/maven-ci-friendly.html ).

As the pom shows, we will (mostly) have one BOM version per branch name used in the system, with version name <branch-name>-SNAPSHOT - same as the module itself. The BOM file should include dependencies using explicit versions, also for system internal modules.

Example flows:

• A simple feature branch. In branch modify pom so the BOM reference refer to same as parent branch - replace ${revision} for the BOM reference. Ie. you don't need a separate BOM (yet...)
• A simple feature branch for internal library. Same as previous, but you should probably create same branch for a module using this library and a same branch for BOM ensuring the two modules are linked.
• A system release. Create a release branch on all modules (git repositories). Including the BOM module. Eg: release201810 . In BOM file in branch release201810 ensure that all referenced system-internal modules are referred to using version release201810-SNAPSHOT .
• Parallell development. Create custom branch on modules as needed. Update the custom BOM as modules are branched for this development.

Is this a good idea?

Answer 1

I have some concerns:

1. You usually put the whole multi-module project into one git repository. Then you branch on the whole project, not on single modules.
2. The whole project usually has a version number in xyz-SNAPSHOT form which is increased over the time. Releases should be built with release versions, while during development you can have SNAPSHOT versions.
3. It is possible to build branches as xyz-branchname-SNAPSHOT, but dropping the version number all together is very non-standard.

I must say that every time I deviated from the standard (for good reasons, like legacy structures in the company), it caused problems later.