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

Branch Guidance discrepancies

Nov 25, 2011 at 3:27 PM

On page 11 of the TFS_Branching_Guidance_Main_2010_v1.pdf that is part of the download, it is written

2. RELEASE branch where you ship your major release from.

a. RELEASE is a child branch of MAIN.

b. Your major product releases from the RELEASE branch and then RELEASE branch access permissions are set to read only.

c. Changes from the RELEASE branch merge (RI) to MAIN. This merge is one way. Once the release branch is created MAIN may be taking changes for next version work not approved for the release branch

d. Duplicate RELEASE branch plan for subsequent major releases.


The two phrases I show in color above seem to contradict each other. They seem to describe two mutually exclusive ways of managing the release branch. if I set the RELEASE branch to read-only as suggested in 2.b, then I cannot make changes to the RELEASE branch implied in 2.c.   It seems to me that the basic branch plan should NOT set the release branch to read-only. Instead, the Release branch is used to develop and deploy hot fixes while future development is done in DEVELOPMENT branch.  Setting the RELEASE branch to read-only seems compatible with the requirement "to have an accurate snapshot of your sources at release time."  That is described in the Standard Plan. But I would not include that in the Basic plan. I would keep the Basic plan as simple as possible.  I believe doing hot fixes in a release branch is the simplest way to support production while allowing development to proceed elsewhere.


However, if one DOES want to lock down the RELEASE branch, then I would reorder the items above.  The problem is that this can be read as instructions to be followed in order, or as general principles.  As principles, there is not a problem.  But if we take the items a-d in order, as most readers will do, then they will experienced this "inconsistency."  Instead, if we reverse b and c, and first say that when we make the release branch, we might have a few ship-stopping defects to repair in the release branch, then we stabilize it and release it, THEN we lock it down and reverse integrate to MAIN - then it would have made sense. But to a newcomer, I fear the order of the items implies order of execution rather than a list of goals.

By the way, If you happen to rewrite this for a future version (like TFS 2011), or produce other items, I would be glad to review them in draft form to help identify points of confusions. I am easily confused so I am a great asset in this regard ;)

Nov 25, 2011 at 4:58 PM


Yes, I agree that these statements are contradictory. As we review the guidance for the next release we should elaborate on these rule somewhat.

Not everyone will need or want to make their RELEASE branch read-only. We recommend this approach particularly when audit or regulatory requirements impose the need to have an archived copy of each major release shipped to customers. Clearly, as you note, when the RELEASE branch is made read-only, there will not be any changes checked into this branch, and thus there will be no need to merge changes from RELEASE to MAIN.

The larger point here is that, once you create a RELEASE branch, you should not merge ANY changes from MAIN into the RELEASE branch. At the time of release, when the RELEASE branch is created, MAIN is now opened up for vNext development. Merging changes in MAIN forward into an existing RELEASE branch will pollute a vCurrent Release branch with vNext changes that are likely not tested thoroughly.

I you want to make servicing changes in the RELEASE branch, then you would not make it read-only or you would use the Standard or Advanced branch plan which provides for a Servicing (SP or Hotfix) branch between MAIN and RELEASE. In these branch plans, changes would be possible in the Servicing branch(es) but not in a read-only RELEASE branch. The same restriction applies to the Servicing branch. You can merge changes from Servicing to MAIN (Reverse Integration), but you should not merge changes from MAIN (vNext) into Servicing branches (vCurrent).

As for ship-stopping defects requiring additional stabilization, this should ideally occur in MAIN before branching for RELEASE. This eliminate the need to RI changes back to MAIN from RELEASE.

Finally I would agree that when bulleted items are numbered or lettered, an order is implied. Perhaps we should use simple bullets in addition to clearer explanations.

Bill Heys
VS ALM Ranger