We are using version in following format:
Major.Minor.Bugfix.Test
Development for upcoming release is going on in the trunk. When enough features are done we are creating a new release branch: 1.1, 1.2 and so on.
After branch is created there is a continuous "stabilizing" process, producing test versions of branches: 1.1.0.1, 1.1.0.2 and so on, until a new bugfix version is ready, those are: 1.1.1, 1.1.2 and so on.
The image below should explain it better:
Upon creating release branch the version in the trunk is increased (since we begin working for next release somehow).
The problem: we also need to use versions in the trunk (those are given for internal tests) and they will collide with the next release branch test versions (marked with red circle).
The question: how to avoid such version collision?
One proposal was to change trunk version after branching to high enough number, e.g. 1.2.0.100, this will make collision unlikely to occur, but is ugly.
Ideally we want to keep numbers "small" (so they are easy to remember and to use).
(Optional) Another thing: after periodic merging from current release branch into trunk it make sense to indicate this somehow in the version too (marked as ? on the picture), could be very useful to indicate that following trunk test builds are have those bugfixes included, e.g. after merging 1.1.1.1 into trunk (which is currently 1.2.0.3), maybe something should happens with version too, not just increment it 1.2.0.4. Not sure what though.
Ideas?
For an easier overview here is an image of one of proposed solutions:
The idea is to inherit (continue) number in release branch. This will solve collision, but will introduce another problem: there is no more 1.1 or 1.2 versions. We'd like to have those if possible.
Best Answer
There are two major strategies that address both your problems.
1. Trunk has a "fixed" version number
You could choose to give the Trunk a version number 0.0.0.X, where only the X ever changes. This then makes it clear to everybody that such builds are part of the active development and not part of the stabilization of a release.
In this concept, it does not make sense to track (using version numbers) when bug-fixes from earlier releases are being merged into the trunk.
It also has the advantage that you only have to decide on which version number to release (increment the minor or the major part) when starting the stabilization.
2. Release branch continues where Trunk ended
If you want your working methods as close as possible to what you are currently doing, then you could just continue the test numbers on the release branch.
If Trunk is at version 1.2.0.26 when you decide to create the 1.2 release branch, then the first build on that release branch would be 1.2.0.27 (and the next on Trunk 1.3.0.1)
In this scheme, you can just increment the BugFix part of the version on Trunk when merging bug fixes from earlier releases.
This scheme essentially uses a different mental picture of the branches
When starting stabilization for a release, you rename Trunk to the release branch and then create a new Trunk from that point for the development of the next release..