The whole confusion stems from the different semantics that MS uses for "Build number" and especially "Revision". The terms just mean different things.
Most people (myself included) use a semantic version numbering scheme where you just get a higher BUILD number whenever you have to make a new build for whatever reason. For us, a hotfix is considered just another code change, and the BUILD part increases automatically with every CI run. Modules with same MAJ.MIN.REV are considered interchangeable, and the BUILD tells you which one is the most recent.
Incrementing REVISION, however, indicates a new permanent release branch, that's why we place it before BUILD. The downside of that approach is, that we might get the following sequence of events:
- commit number 4711: Alice added feature A
- CI produces build 220.127.116.11
- commit number 4712: Bob modified feature B
- commit number 4713: Alice fixed feature A (the "hotfix")
- CI produces build 18.104.22.168
As you can see, the hotfix is not the only change contained in the next build, also Bob's modification become part of that build. If you want to stabilize the current branch, you may run into troubles as you never can't be sure whether or not Bob just added a bunch of bugs.
MS uses both terms differently. The BUILD number is not automatically incremented, instead it can be considered being kind of a release branch, to freeze the code used for a particular version of the code. The REVISION indicates additional "hot" changes applied to that BUILD branch. The sequence would therefore be as follows:
- commit number 4711: Alice added feature A to trunk/master
- Carl creates build branch
- CI produces build 22.214.171.124
- commit number 4712: Bob modified feature B in trunk/master
- commit number 4713: Alice fixed feature A in the
- CI produces build 126.96.36.199
The term REVISION may refer to
- a product revision (that's how most people use it)
- a revision of a particular daily build (that's what MS does)
The key difference between the two processes is, whether or not you want the ability to apply hotfixes to CI builds and thus, at which point in the process the branch is made. This aspect becomes important when you want to be able to pick a particular build at any time after all the tests succeeded and promote exactly that version to the next official release of your product.
In our case the CI tool creates a repository tag, so we always have the necessary information ready to use, when needed. With SVN it becomes even simpler, because tags and branches are implemented exactly in the same way - a tag is nothing more than a branch located under
From the FAQ section at TFS branching strategy:
In what branch should I fix the P1 (hotfix) ticket?
The P1 should be fixed in the branch that is closest to the code base running in Production. In this case the P1 should be fixed in the Prod branch. By applying the fix in any other branch and rolling out the changes to production you risk releasing semi-finished or untested code from the subsequent iterations.
Now you may argue if it is safe to work directly against the Prod branch, think again, a P1 that requires immediate attention should not be a fundamental problem in the system. In case it is a fundamental problem it should be added to the Product backlog as it may require further analysis and discussion with the customer.
Another good read is the TFS branching guide