One characteristic of labels in TFS to be aware of - they are not immutable. You can probably achieve your goals by labeling your code with each release (6.5, 6.5.1, etc.). But TFS will not prevent you from modifying the *contents* of a label after it is
applied to a branch. This may cause problems with auditors who want the contents of release *locked down*. This is one reason we recommend creating a release branch for each release, and locking it down. Since you need to be able to apply bug
fixes to any prior release, you would need perhaps two branches for each release. Branch Main -> Servicing and then branch Servicing -> Release each time you do a release.
Lets say you have just released version 6.5.0. You could branch Main to create a Servicing 6.5. Label the code Release 6.5.0, but also branch Servicing 6.5 to create Release 6.5.0 and lock it down.
Now you need to create a bug fix against Release 6.5.0 - apply this bug fix in the Servicing 6.5 branch and release it to your customer. Label the code in Servicing 6.5 as Release 6.5.1 but also Branch Servicing 6.5.0 (with the hot fix) to Release 6.5.1
and lock it down.
Now if you need to apply a second bug fix to Release 6.5.1 make this fix in Servicing 6.5 (which now has the code for 6.5.1 as latest version). Make the fix in Servicing 6.5. Label the code in Servicing 6.5 as Release 6.5.2 but also branch Servicing 6.5
to create Release 6.5.2 and lock it down.
Each time you get a new bug fix for Release 6.5.x the fix would be made in Servicing 6.5 branch, but you need to decide which sub-version of the code to apply the fix to. It could be either 6.5.0, 6.5.1, 6.5.2. You should have a label you can roll back to
if you do not want the bug fix against the latest version.
Later when you release version 7.0.0, you would branch Main to Servicing 7.0 and then branch Servicing 7.0 to Release 7.0.0 and lock it down.
If you are concerned about the overhead of creating a new lock-down branch for major Release and each minor hot-fix you could probably get by with only creating Release branches for the major releases and not each hot fix. Nevertheless, read my latest blog
to gain a better understanding of the actual overhead involved in creating a new branch: http://www.tinyurl.com/tfsversioning.
Normally when you have a one-to-many relationship in a hierarchy (such as a branch hierarchy), you would make the *one* the parent and the *many* children of the parent. You might think you want to invert the relationship between the Release branch and the
Servicing branch, since you have many possible bug fixes for a given release. But if you invert the relationship in this way: Branch Main to Release 6.5.0 and then branch Release 6.5.0 to Servicing 6.5.1 and later branch Release 6.5.0 to Servicing 6.5.2. But
when you put the servicing branch(es) as a child of the Release branch, you cannot merge the bug fix back to Main without merging it into the Release branch first. You would no longer have a copy of Release 6.5.0 (as released) since you would have merged post-release
bug fixes into it in order to get them all the way up to Main.
VS ALM Ranger