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 branching...how 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.
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
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.