Support for Monorepo with Independent Versioning for a Submodule

[lobaorn]

trafficstars

Hi @qoomon,

I’m configuring maven-git-versioning-extension for a monorepo and need help setting up versioning rules that support my workflow. Here’s the setup:

Monorepo Structure

• The monorepo has a root POM and multiple submodules.
• By default, the root POM and all submodules share the same versioning strategy.
• One specific submodule (decoupled) must be versioned independently, using a separate branch and deployment flow.
• Unlike the other modules, decoupled does not follow a separate release or hotfix branching model. Instead, all development, fixes, and releases happen within the decoupled branch itself.

Branch Strategy & Versioning Rules

The monorepo follows this branch structure:

main │ ├── DEV (feature development, constantly updated with PRs) │ ├── feature/* (new development branches) │ ├── release/* (branched from DEV at release time) │ ├── hotfix/* (created from main for urgent fixes) │ └── decoupled (dedicated branch for independent submodule decoupled, used for all changes, fixes, and releases)

Expected Versioning Behavior

Branch	Expected Version Format
DEV	1.x.0-SNAPSHOT
release/x	x.0.0
hotfix/x.y	x.y.z
main	Latest stable version
decoupled	Independent, 2.x.0-SNAPSHOT (used for development, fixes, and releases)

Question

How can I configure maven-git-versioning-extension to support this workflow? My key challenges:

1. Ensuring DEV uses -SNAPSHOT versions, even when merged frequently from hotfix/* and main.
2. Keeping release/* and hotfix/* versions correct when branching from DEV or main.
3. Applying a separate versioning scheme for the decoupled submodule, ensuring that all changes (features, fixes, and releases) happen in the same decoupled branch without requiring additional branching.

Would love any guidance on how to structure versioning.yaml to achieve this! Thanks in advance.

P.S.: Our current solution does not have the decoupled branch/module and that is what we are aiming. Right now there is a legacy strategy in place, that use sed in some parts and external tooling, also https://github.com/cecom/pomutils to auto-resolve conflicts in pom during merge, and I am evaluating options to present to the team responsible.