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.
