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

How to propagate fixes from older releases to newer ones

Sep 8, 2010 at 5:34 PM

Hi all,

after reading the TFS Branching Guide and comparing it to our (homegrown) branching concept, I wonder how bug fixes that take place on a hotfix branch (for V1) are merged to a newer release (V2), such that no regressions occur.

I understand that if V2 does not exist yet at the time the hotfix is created, the fix would be eventually merged to MAIN, and thus automatically become part of V2 at the time of creating the new release branch - so far so good. However, if both V1 and V2 have already been released, and the hotfix is applied on V1, how does the fix become part of V2?

Thanks for your ideas!

Sep 8, 2010 at 6:17 PM

In your scenario, you have released V1 (vCurrent - 1)  and V2 (vCurrent) of a product, and presumably you are working on V3 (vNext) in devlopment. You identify a bug in V1 in production. You need to fix this bug, in V1 and V2 in production, as well as V3 in development.

Baseded on the nature of the bug, you decide you need to make this same fix in production for V2 and also in development for V3. Since the Main branch and the Development branches have moved on for vNext development, you cannot fix the bug in the development branch and merge it into the V1 or V2 production. Doing this would risk bringing more than just this change down into the V1 and V2 Production (Release) branches.

My recommendation is to make this change a hotfix servicing branch for the version where the bug is initially identified (in your scenario in V1 hotifx). To get this change into the V2 production release, you have a couple of choices. You cannot merge the change into Main and then do a full merge down into V2 Release (or V2 Hotfix) for the reason described above. You  might condsider doing a  *cherry pick* of the affected changeset(s), and merge them from the V1 Hotfix branch directly into the V2 Hotfix branch. Alternatively, depending on the magnitude of the changes, you could simply modify the source in both branches (V1 hotfix and V2 hotfix) simultaneously.  Cherry picking a changeset from V1 Hotfix to V2 Hotfix will probably require a command-line baseless merge, since there typically is no merge relationship between these two branches in the normal circumstance.

As you note, the change will probably be merged back to the Main branch (probably from the V2 Hotfix branch. From there it will be merged from Main to the Development branch(es) on the next good build of Main (or after more thorough testing of the change in Main). In this way the fix will become part of V3 (vNext).

Bill Heys
VS ALM Ranger

Sep 10, 2010 at 10:56 AM

Hi Bill,

thank you for your answer, it's exactly what I was looking for!

Unfortunately, as you correctly note, I'm left with two equally unpleasant choices:

1.) do a command-line baseless merge aka. "cherry picking" from V1 to V2;

2.) fix the bug manually in every released version (duh!).

We're about to migrate from Subversion to TFS, and I honestly don't want to propose either option as the new "bugfix propagation concept" to my 20+ developers... Honestly, I wonder how others are dealing with this issue (I was assuming that supporting multiple older releases is what every software development company needs to deal with).

Any thoughts?


Oct 30, 2012 at 6:47 PM

Stefan, how does Bill's guidance compare to what you were doing previously?