How to manage versions on monorepo with application requires to support multiple releases

Hmm, well I have a .net example which might be technology agnostic.

I'll just do a quick summary.

• git repo per component with gitflow branching strategy

• all commits to develop trigger a team city build

• teamcity build amends the version with manual major minor + the build number in AssemblyInfo.cs ie 1.1.hotfix.build

• teamcity triggers nuget packaging using the same version number for nuget published libraries

• octopus deploys finished build to qa for manual testing (assuming all tests pass)

• if everything is good, manually deploy version to production via octopus.

Now this does mean you get A LOT of versioned packages floating about. We did experiment with use of the -prerelease flag but this required a further manual move package from prelease to 'normal' step and a requirement to rebuild components which depended on them.

The key thing is to version every build uniquely via some central process.

Then you are in the situation of 'hmm what versions do i want' rather than 'omg, what version have i got??'

Edit: re comments.

Just to underline that key thing really. Decide what branch constitutes completed software and version ALL commits to it. only deploy versioned software from this branch.

My view though is that you need to address your branching strategy.

• don't version feature (or any dev) branches.
• do version master
• only use packages from master

A simple solution, not just for agile teams, is to separate the engineering version from the marketing version. One well-known instance of this is Microsoft's versioning for Windows NT:

• the very first version was 3.1, not 1.0
• marketing version Windows 2000, engineering version Windows NT 5.0 (MS had decided to stop development of the DOS-based versions, and consequently dropped the NT from the product name, despite the fact that at the same time, Windows ME was released)
• marketing version Windows XP, engineering version Windows NT 5.1
• marketing version Windows XP Professional x64, engineering version Windows NT 5.2 (Interestingly, the port to AMD64 got its own version number, whereas Windows XP 64-Bit Edition, the port to IA64, did not)
• marketing version Windows Vista, engineering version Windows NT 6.0
• marketing version Windows 7, engineering version Windows NT 6.1 (actually, the engineering version was 7.0 originally, but Microsoft found out during compatibility testing that a lot of software was testing for major == 6 to figure out whether to enable post-XP features, and rather than breaking all those apps, Microsoft decided to revert the major version to 6. During the keynote, they joked that Windows 8 would have version 6.1.1, and so on, for the same reason.)
• marketing version Windows 8, engineering version Windows NT 6.2
• marketing version Windows 8.1, engineering version Windows NT 6.3
• marketing version Windows 10, engineering version Windows NT 10.0 (MS re-aligned marketing and engineering versions with Windows 10, however due to the new rolling release model, it is imaginable that the engineering version may change but the marketing version stays the same)

[Note that Microsoft also has release numbers as well as monotonically increasing build numbers, none of which show up in the marketing versions.]

So, you follow SemVer for your engineering versions (which, in an agile project will likely lead to high version numbers), and the marketing department is free to chose their versioning scheme however they want. You can think of a marketing version as a human-readable short label for a set of features that just so happens to be formatted like a version number.