This project has moved and is read-only. For the latest updates, please go here.

Basic Branch Plan

Jun 1, 2010 at 8:54 PM

Is each subsequent release a new branch (so that it is basically a "copy", an alternative to a label, so you can get back to that release if needed)?

Or if you don't need prior releases (as with typical inter-company software), should one use Forward Integration to refresh the release branch at release time?



Jun 1, 2010 at 8:57 PM
Edited Jun 1, 2010 at 8:57 PM

Nevermind - I found the answer.  There seem to be a lot of docs to juggle in this guideline.  Following is quote from page 6 of TFS_Branching_Guide_Main_2010_v1.pdf.  Would have been nice to see this on the "Basic Branch Plan" diagram.

Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release2.0 branch is peer to release3.0 and both are children of MAIN).

Jun 1, 2010 at 10:28 PM

As you correctly determined, in a multiple release scenario, each new release would be a new branch (or set of branches) from the MAIN branch.

In TFS, Labels are NOT immutable, so it is possible that you label your code, release it, and then modify the label (to perhaps include a bug fix). In this scenario, the code in the label would NOT be the same as the code you released.

For this reason, our branching guidance suggests making a read-only branch with the code you release. This would allow you to get back to the release whenever you need to.

In general, we recommend against doing a forward integration (from MAIN to an existing release branch). In the scenario you mention: you don't need prior releases, and you are doing the Forward Integration at release time, I suppose you end up with the same thing as if you had created a new release branch for the next release (and then deleted the existing release branch for the prior release).

Our recommendation against doing a forward integration is based on the assumption that you want to keep the prior release branch, and that you do not want to bring forward changes from  the next release into a branch for a prior release.

As long as you understand the concerns, you could probably choose either option (new branch or FI from Main at release time).

Bill Heys
VS ALM Ranger