Software Versioning

Software versioning for the end consumer is a very vital part of the software release cycle. It is one of the primary identifiers for consumers to report issues against in a software. It also helps the development team to identify, if the features/bug fix made it through the release.

We follow a similar pattern, which can be useful for you too. The version number is strongly tied to the SVN (also valid for other version control systems) branching and tagging convention. Hudson (CI server) also plays an important role in stamping the build number.

Convention: productRelease.majorRelease.minorRelease.patchRelease.buildNumber

• productRelease: Also called as the platform release, generally used when there is a huge overhaul of the application framework or platform.
• majorRelease: Is the interim release like a Q1, Q2 release. Q1 would be called at 1, Q2 as 2, when a huge set of features is released, then we increment this version number.
• minorRelease: Since we follow a two week sprint, after every two weeks the counter will increment by 1.
• patchRelase: So the minorRelease made it past QA, but has some issues, when these issues are fixed and redeployed as a patch, the counter is incremented by 1.
• buildNumber: The build number is generated by Hudson and will be appended as the last id.

So how does this affect the usage of Subversion. Before we get into those details, there are a few ground rules for subversion you'll have to follow, once every Release is released, tag it and create a branch to maintain it.

• Considering the starting stage, mark the platform release as 1; 
• Once we release the first sprint; a new branch called 1.0.1 will be spawned off and 1.0.2 will  continue on the trunk.
• Any patches to be released on 1.0.1, will be further branched as 1.0.1.1 and will be supplied to QA on blocker fixes post 1.0.1 release.
• Once 1.0.1.1 is released, it'll be merged back to 1.0.1.
• If further more bugs are found, they'll be released at 1.0.1.2 following the same process.
• No one will dual commit the changes from the branch to trunk, if the fix is for a patch, it'll only be committed to the patch branch.
• Once the patch branch has been cleared by QA, it'll be merged to the minorRelease branch.
• Once the second patch has been cleared by QA, it'll be merged to the minorRelease branch and then the minorRelease branch to the trunk for the next minorRelease.
• There should be not not more than 2 patches for one minorRelease, (considering a 2 week sprint)
• The second patch merge date is a 2 days maximum before the next minorRelease.
• The changes from patches will only make it to the minorRelease branch or the trunk, via branch merging.
• Every release will also result in the tag of the same name. 
• The branch merging should be performed by all developers in a cyclic fashion, so everyone is well versed with the process.

Along this route, Hudson will keep building, automated testing the build, and this build number will also hold reference when releasing a build, every subsequent build need not always be released to QA, there can be 20 Hudson tests and builds before being released to QA.

The numerous branching and merging might sound like a overhead, but will result in a more cleaner release process. Patch releases should not be one class or js file hot-patched, but a complete new fresh build, for redeployment.