Branching in TFS for yearly release schedule?

Question

Question: What is the best practice for creating branches for development and release based on the information provided below?

Background: I work in a small development team (2.25 frontend, 2 backend), and we have a yearly release schedule. Our environment does not allow for patches or services packs mid-year, but every once in a while if our user's environment changes we will release a "recompiled" version with a few bug fixes thrown in (on the current stable version).

Currently we do all of our development on the mainline and then create a branch (5 so far) for the code freeze and do minor bug fixes and the bulk of our testing. Once the version is sent out for layering and deployment we merge these bug fixes back to the mainline where we have continued to develop new functionality for next year's release. The branch stays in our repository forever.

The way TFS does its branches is by having a new "folder" in the source control, and it is starting to get a little cluttered.

Thoughts: Maybe the way we are doing this is right, but it just feels like in a few more years there will be a large number of branches that are never going to be touched... seemingly ever. Maybe it is possible to create a single "Stable Release" line that has each new version labeled on it, and then if we need to go back to do a mid-year release then it can be recovered from this single line.

Answer 1

• Upgrade your environment to 2010 ASAP - TFS 2010 branching is vastly superior, including management.

• Your idea sounds about right - you branch off a release version when you have one, then just fix it.

• You just have to live with the versions accumulating. This makes sense - until you totally retire one (and "never" is not real here, I bet after 7-8 years you kill an old version) there simply is no other way.

Answer 2

A few places I have worked would handle that like this:

• Devs never touch "main" branch directly and it always represents what is in production
• A single "maintenance" branch is used for all of your changes throughout the year.
• At the end of the year, after all of the changes are ready to go, label everything approprirately and the maintenance branch is merged back into the mainline. A new release build is prepared from the mainline and sent out.
• Ongoing changes happen in the maintenance branch.
• Rinse and repeat as needed.

Benefit is that you only ever have 2 branches. That makes some SCM related tasks easier to deal with since you don't have to keep dealing with changing folder names, etc.