Jun 3, 2010 at 10:58 AM
Edited Jun 3, 2010 at 11:08 AM
I have a question regarding the practicalities of implementing our branching model in 'TFS team buildi, in particular how team build should handle version stamping in the Release (Test/Pre-Prod) branches. Here is our branching topology:
- Dev2 (only needed if we need concurrent vNext development whereby the changes are in conflict with Dev1 - we are trying to remove the need for this via better iteration planning)
- R1.0 (Remains here for hot fixes which will build on top of each other)
- R1.1 (as above)
- R1.2 (The current release being tested and stabilised for RTM)
RTM (Read Only branches for auditing purposes only, we have found this better comparing back through version history of the Release branches in terms of giving non Development Team Members read only access to sections of the source code)
Our Dev and Main team builds take the standard '[BuildName]_20100603.1' naming convention in team build. We also have a distinction between a build and a release in our build definitions whereby a build simply does a compilation on the server only for
all check-ins, with a release doing this as well as putting the output in the drop area. We intend to have gated checkins to our dev and main 'builds' in the near future.
We perform early beta releases directly from Dev Branches for testing, and a fully integrated release for manual testing will be done from the most current Release Branch (Test/Pre-Prod). We have automated some of the testing.
It is not clear whether when a stabilising a production release coming from the current release branch (E.g. R1.2), which has the potential to go through a few manual testing cycles, should be version stamped in the same manner as Dev and Main with a datetime
stamp, or whether it should commence proper version stamping such as V1.0.0.
There appears to be trade offs under both scenarios.
If datetime stamp versioning is used: A Release would need to have its version changed on the decision to turn it to RTM. Changing a version number doesnt appear possible in the team build explorer. Another build agent or build definition could be setup
to do a production release over a branch which will do a version stamp, but then the release will have 2 identities, which is sounding too far away from the out of the box intent of 'Build Quality'
Each Release gets a proper version stamping every time: This works perfect in the team build explorer as you would simply change the build quality to "Release", but the problem is here is that you would start burning V1.0.x numbers. From an aesthetic
point of view there would be gaps in the version numbers in your read only RTM area. The first version of V1.0 that is released could be say V1.0.7 and not V1.0.0. It would be preferable that the first release always goes out as V1.0.0 with only hot fix released
incrementing the second number and in a sequential manner. This sounds more align with best practices and maybe we just live with the 'gaps'. Most of the concerns about gaps have been raised by management, the Development team is not too fussed about
it but we are having trouble as we havent found anything in the industry to suggest that this is the norm.
Interested to here anyones thoughts on this.