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

Why create release branch with Hotfix branch?

Mar 23, 2012 at 2:14 PM


I recently did a source control migration from Subversion to TFS. In Subversion our developers were doing the following (regarding creation of the release branches):

  1. When the version in trunk (Main) was feature complete they created a "Release" branch. Usually named by the target version to create (equivalent to the Servicepack/Hotfix braches).
  2. Then this version was tested, show stopping bug fixes were made on this branch.
  3. When the testers said the version is OK, a tag was created (kind of a read only branch) and the tagged version was delivered.
  4. When a customer requested a bug fix of a release version. The bug was fixed on the "Release" branch and a tag for the new version was created.

To me this sounds totally reasonable, so why do you recommend branching "Servicepack/Hotfix" and "Release" branch at the same time and say in the definition of the release branch that it is "A branch where ship stopping bug fixes are made before major product release.".

Isn't it more effort because I will have to merge my Release fixes before delivery back into "Servicepack/Hotfix". In our Subversion solution, the pre release fixing is done in the same branch the post release hot fixes are done in. So now merging is necessary.

Is there something I don't see here?

Apr 15, 2012 at 4:03 AM

Great question.  Only branch if you need to, and always keep it simple is the tone I hear from the above, and I definitely agree.

As with most branching patterns, there is not necessarily a right/wrong and we have the pros and cons with every new branch.  The worfklow you describe does sound reasonable.  The recommendations to create a service pack, hotfix branch apply to a specific pattern, but are not a hard requirement for every scenario.  Some of this comes down to how many release vehicles you intend to support in parallel at one time in prod, and with all much isolation you need in your development efforts.  Your plan above sounds very similar to our "Basic" plan.

So it sounds like you should implement the basic plan, and that will work for you.

However...Let me play Devil's advocate:  :)

Not knowing your entire hiearchy, release strategies, dev branches, etc make it hard to answer exactly:  In your example if I were to need to be doing development on a SP, where would I do that longer term dev ?(i assume the single release branch, I can't do it on Main as that is where next version is happening I assume)

What if I were doing dev on a SP, and we find a critical bug fix that needs to be fixed before the SP is ready?  I can't use the single release branch now, so I'm needing a place to do that work.  There are other reasons:  Some enterprises will insist that a branch be frozen in time once released, and never touched again for auditing (Read only).  It is not the only way...A label could work here, or a log entry of the changeset.  There are many ways.   If these scenarios don't pertain to you, then definitely keep it simple.

The good news is with TFS, you can branch "on-demand".  One pattern you might consider is just to mmic what you mention above (again looks like basic plan to me), and if you were needing the extra branch just do it if the time comes. 

We are addressing some new patterns in the latest guidance as well as expand on differentiating between development branches and release branches a bit better.  Some of this in our beta guidance, and the story will be more complete as we get closer to RTM, as we draw out more precisely the pros/cons. 

Below is a copy paste from the beta guidance.

Basic Branch Plan

The basic branch plan with a main, dev, and release branch enables concurrent development for your next release, a stable MAIN branch for testing and a release branch for any ship blocking bug fixes.

Multiple development areas are supported by creating additional development branches from MAIN.  These are peers to each other and children of MAIN.

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).  If supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch as depicted in the diagram below.

Once the release branch is created MAIN and the development branches can start taking changes approved for the next product release.

Advanced Branch Plan

The Advanced plan is for products that must support many release vehicles and servicing scenarios.  The plan allows for concurrent development of a major release, service packs, Hotfixes and next version work.  By adding a Hotfix branch between the Service Pack and Release branches, you add another level of parallel development as you may develop and release critical bug fixes via the Hotfix branch while doing longer term feature development, and less critical bug fixes on the Service Pack branch.  You may create new release branches, as well as retire or delete old release branches, and you can also leverage security settings to ensure release branches are toggled to read only.  This plan also allows you to support multiple releases in production at one time due to having multiple release branches.



Mike Learned.

Jul 18, 2012 at 12:37 AM

I agree with Mike, that you should ONLY branch when the benefits outweigh the costs (of merging or not isolating parallel development).

I do take a strong position on some branching principles:

  1. Every "Release" branch should be locked down (made read-only) immediately after it is created.
  2. Since every Release branch is locked down when created, post-release changes "require" a Servicing branch. While it is preferrable to know in advance that you need to support post-release bug fixes or SPs (and create the servicing branch first, and branch the Release branch from the Servicing branch), you "can" create the proper structure at a later point in time if you need to. I would suggest creating a "new release" branch from the locked-down "Release" branch, making the new branch read-only and making the "Release" branch changeable (for bug fixes). The new structure would go from Main > Release (read-only) to Main > Release (changeable) > Release_New (read-only)
  3. Labels are not immutable. Label contents can be changed after they are created, and they are not auditable. Labels are therefore NOT a substitute for separate "Release" branches (which are auditable)
  4. If you never need to make post-release fixes, the basic plan should work for you. Nothing in the Basic plan precludes you from having multiple Release branches (locked down) for auditing purposes.
  5. If you require post-release support, then consider moving from the Basic plan to the Standard plan.
  6. If you require "both" post-release bug fixing and periodic ServicePacks, then consider moving to the Advanced plan. Remember, in each of these plans, you can support multiple releases by repeating the Release branch structure (e.g. Main > SP 1.0 > Hotfix 1.0 > Release 1.0 (locked down) and Main > SP 1.1 > Hotfix 1.1 > Release 1.1 (locked down) and Main > SP 2.0 > Hotfix 2.0 > Release 2.0 (locked down)