How to version number a project?

Question

I have a maven multi-module project with more than 6 children modules in it. If a team of 3 is working in parallel taking 2 sub-modules each as their task, then how to increase the version number.

whereas I am following Major.minor.patch-meta format for version numbering in release cycles.

Project A
   -- sub-module-assembler 
      pom.xml
   -- sub-module-1
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-2 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-3 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-4 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-5 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-6 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
--pom.xml

Exact usage of incrementing and decrementing version numbers in parallel programming, Whereas the key thing to be notified in this is some sub-modules in that project totally depends upon some other sub-module, if that is the case then how to version number exactly while the development goes parallel as well in certain order ?

I am not clear about the below but is this right way of version numbering

1. Should i need to do meta release in case of bug fix e.g alpha, beta , gamma etc.,

2. Should i need to do a patch release in the case of completion of a feature[sub-sub-module-x] in a sub-module whereas i am using second level+ sub-modules e.g 0.1.1-alpha, 0.1.2-alpha etc.,

3. Should i need to do a minor release in the case of completion of a sub-module e.g 0.2.0-alpha , 0.2.0-RC etc.,.
4. So after integrating all the RC's 0.2.0-RC + 0.3.0-RC + 0.4.0-RC etc should i need to do a major release as 1.0.0-RTM etc.,

So understanding the above flow is bit cofusing ..

Is there any way to automate the build numbering in a project so as to maintain clear build release numbers. Please provide a solution.

Thanks

Answer 1

I suspect there will be no answer for all versioning strategies. But let me try some hints that may help you choosing a strategy that is appropriate for your situation.

The project looks rather big. The first grouping I would do is by responsibility. Are there modules that are restricted to a certain development team? Or is the whole thing maintained "all-in-one"? Hopefully you are able to split it up a bit. Once you know about module(s) responsibilities you need to define some life-cycle. How and how often is a release (or bugfix, patch) created and by whom? If everyone follows the same rhythm you can share one version and release the whole tree. But usually this is not the case in larger projects. It also introduces side effects during development if a lot of people share one version.

If you do not plan to release the complete tree all at once you may split it more consequently. You can still use a common parent pom.xml (but one with a released version).

I would define one version for modules in a parent pom.xml and inherit it. So no individual version in submodules. Furthermore every team that depends on other modules should not use SNAPSHOT dependencies to work of other teams. They may only use a released version (be it BETA or RC1). It is important to keep builds reproducible. E.g.: "no snapshot dependencies to artifacts you are not in charge of (you control what changes and when)"

As for the versioning itself: in doubt the simpler option may be better. All the meta information may only confuse about the actual state?

What may also be of some use is to draw a deployment pipeline: what module comes first, which ones depend on it and so forth. The amount of changes in one module define how the version changes (major, minor, patch change). If those changes do not propagate across modules (the API stays stable, which is your goal) the next module may only do patch releases.

If you have not yet released anything, plan ahead. Every iteration is usually an API change (therefore it actually would be a major release). That would lead to version 18.0.0 to be released (after 18 iterations). So usually the minor version is used to indicate iterations and patch versions indicate some fixes to stabilize that release. So major versions are chosen more from a marketing aspect than from a technical one.

It also depends somewhat on the type of software you build (a product, an in house-solution, some additional service for your landscape). Products have a much clearer versioning, they usually use the META part to indicate iterations and the major.minor.patch numbers to indicate what is going on. That strategy ("indicate what changes to expect") may help for what you are doing as well?

So hopefully this did not raise more questions than you had at the beginning :)