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
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