With Vault, should one prefer Labels or Branches when isolating release code bases ?

Question

When isolating code for a release, is there any advantages to using "labels" over "branches".

The process we follow is to branch code close to release and stabilize the release on the branch. After release is approved by SQA we merge changes back to mainline.

Other dev groups use labels to 'isolate' the code base used for a release. I don't like this for following reasons (which may be wrong):

• vault doesn't support merging from labels to other labels. The merge support between branches is excellent
• can't remove permissions on labeled items to stop modification. you can restrict access to branches.

Thoughts appreciated.

Answer 1

This is just my viewpoint below. I think there are many ways to do it, but I think you got it right in that branches are better than labels for this sort of thing.

Here's how I think of it:

The code under trunk is the code that is going to production. If there is code in there that is not going to be used in the next release, that code should be moved to a branch.

Branches are then used to track future developments. So, tomorrow, create a branch (Branch A), from the trunk, and start adding feature A. Once SQA approves of Branch A, merge it back onto the trunk and push trunk to production.

Notice, in that case, that Patch X could be made to the trunk. You might need a simple 1 line change and a quick test and regression test by SQA to vet Pathc X. But because feature A was being developed on a branch, it wasn't holding up the release of Patch X.

Any time you release Trunk to production, throw a label down across all of trunk that marks when a certain version was released. The point with the label is to be able, at a later date, to retrieve the exact code that was released at a certain point.