Below is a branch plan that I've used before that enables servicing a released product with hot fixes, a cumulative service pack (SP) and enables next version work in main and the development branches. This is also simplified version on the branch plan used for Windows development at Microsoft but could also be useful in your organization if you have similar servicing requirements.
Branch planning, like many aspects of application lifecycle management, does not have canned solutions that work for everyone. I'll step through the details of this branch plan and hopefully parts of this will apply to your project and a starting point for your own solution may emerge.
Goals
This branch plan enables concurrent hot fix, SP and v-next development. It also ensures that changes can be checked into on branch and merge into branches of future releases.
A by-product of this plan is that you should see fewer regressions from "lost" changes and reduced merge conflicts since changes are checked into one branch.
This post does not go into much detail on check in policies, quality gates or build frequency. For that information you may want to start with the branching guidance on codeplex.com or look for later posts here in those areas.
Definitions
These definitions are used in the graphics for this branch plan. The definitions I provide below are a bit more generic than the official MS servicing definitions. Hopefully these broader definitions will make this branch plan apply to more situations.
Release vehicles
The release vehicle is how code leaves your organization. For any branch plan to work you must define precisely the different ways that code leaves your org and gets to a customer. In this example we have 3 release vehicles.
Once the release vehicles are defined you build a branch plan around these that enables code to be checked in once and merge back to main.
Branch plan in action
From development to main there should be regular forward (FI - parent to child) and reverse (RI - child to parent) integrations. Once the code in main has reached some objective measure of release quality (e.g. bug count, test pass %, preview feedback, etc.) then it is time to create the production/release branch for this release.
The key to this branch plan is that the SP, Hot fix and RTM branches must be created in order to assure the parent child branch relationship is maintained.
In TFS the physical layout of the release branches would look like this.
$/project $/project/development/dev_team1/source (branch from main/source) $/project/development/dev_team2/source (branch from main/source) $/project/development/dev_teamX/source (branch from main/source) $/project/main/source $/project/production/V1/SP/source (branch from main/source) $/project/production/V1/HF/source (branch from release/V1/SP/source) $/project/production/V1/RTM/source (branch from release/V1/HF/source)
If the spaces format correctly, you should see that the production branches SP, HF and RTM are children of each other. In the production branches the further from main the branch check in policy is usually more restrictive.
Once the production branch plan is created main and the development branches move on to "next version" work. In this example we will call this V2.
Any changes for the V1 release happen in the appropriate branches based on the specific criteria below.
Changes should be RI'd in from RTM->HF->SP->main only. This will ensure future releases are regression free as fixes will integrate into the next cumulative release (i.e. all hot fixes will be merged into the next service pack). Do not FI changes from main to SP after the initial release branches are created. An exception may be for merge specific change sets as needed for a HF or SP release.
This plan also supports n service pack releases and hot fixes for those service packs by branching from the SP branch.
$/project/main/source $/project/production/V1/SP/source (branch from main/source) $/project/production/V1.1/HF/source (branch from production/V1/SP/source) <-V1 SP1 hot fixes here $/project/production/V1.1/RTM/source (branch from production/V1.1/HF/source) <-V1 SP1 release here $/project/production/V1.2/HF/source (branch from production/V1/SP/source) <-V1 SP2 hot fixes here $/project/production/V1.2/RTM/source (branch from production/V1.1/HF/source) <-V1 SP2 release here
Conclusion
This is a specific branch plan that enables concurrent hot fix, service pack and v-next releases. Each branch is associated with a release vehicle to give the developers checking in a clear map of where their changes should be checked in depending on what release they are working on.
This plan also allows for a single check in to have a clear merge path to main to reduce regressions and merge conflicts.
Also, having a strong association between your branches and the release vehicles will keep the whole organization aligned on very specific releases and expose work that is not focused on a particular release.
If you product has similar release vehicles and servicing requirements then this plan may be a good start point for you.
Reference
TFS branching guidance http://www.codeplex.com/BranchingGuidance
Microsoft servicing terminology http://support.microsoft.com/kb/824684