Maintaining old software product versions in TFS

We used to have the usual regular software releases - once or twice a year - and branched our code in TFS in order to support hotfixes or patches - whatever you want to call them.

Now we are releasing a new version every two weeks and are trying to figure the best way to manage hotfxes. One option of course is just to assume people will upgrade to the latest version, but in some cases that isn't practical, so I was trying to think of how TFS could support this.

Each release gets labelled, so getting the original code isn't a problem, it is making sure you have the current patched code if no branching is being done.

I did wonder about having each developer check in their hotfix changes to a shelveset with the label name in it - so getting the latest hotfixed version would be a matter of finding all the shelvesets containing that label name and checking them out in date order, but TFS doesn't support searching on shelveset names.

I then wondered about developers sharing the same shelveset - to the same shelveset would be used to store all the hotfix changes for a particular version - but developers can't check in to a shelveset that someone else created.

So can anyone think of a good solution to this?
purplesoupAsked:
Who is Participating?
 
Bob LearnedCommented:
If you are saying that you apply hot fixes that frequently, then I would agree that you are in a pickle...

You are going to need an area where multiple developers can work on the same code set, and branching is the only way that I can think of right now.  I never needed to figure out any other way.  I certainly am not in the situation where I create that many branches, but I do understand the headache that can cause.

I was reading a few discussions, like this one, that sounds familiar here:

Why create release branch with Hotfix branch?
http://vsarbranchingguide.codeplex.com/discussions/349773

I ran out of time this morning, but here is a possibility that might get what you want:

Simplifying TFS: Applying hot fixes without branching
http://www.olegsych.com/2009/04/simplifying-tfs-applying-hot-fixes-without-branching/
0
 
Bob LearnedCommented:
I remember a Branching and Merging Guide, that explained the different options depending on your requirements, but I am having a difficult time finding that nice pictures that showed each option flow.

I am thinking it might be this:

Chapter 5 – Defining Your Branching and Merging Strategy
http://msdn.microsoft.com/en-us/library/bb668955.aspx
0
 
purplesoupAuthor Commented:
Thanks - this is the thing, we can't branch every two weeks things would just get crazy, that's why we're looking at what other options exist.
0
 
Kyle AbrahamsSenior .Net DeveloperCommented:
To keep things more manageable you might force them to upgrade.  EG:  If you're 3-4 for versions back, you must update to the latest program.  

Branch by Release is the most sound model that I've heard of.   Maybe you can make it modified in your case.  EG:  Do a branch by major release (say, once per quarter).  All hotfixes for that major release get checked into that branch (and merged to the trunk and any later branches, of course).  If people need the hotfix they'll need to update to the latest code of that branch at least.  The brances could survive a year before dropping off and being forced to upgrade.

To replicate your minor releases a label would be needed on that branch.  But the support approach would be to always update to the latest specific update of that branch.
0
 
purplesoupAuthor Commented:
Thanks that's all very helpful.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.