Q:

Refactoring and concurrent development branches

Let's say you have several maintenance branches for existing releases of your software. Some developers are making direct changes in the maintenance branches, and merging periodically into the trunk. Now comes an extensive refactoring in the trunk codeline, scheduled for an upcoming major release. But this makes the maintenance branches fundamentally incompatible with the code in the trunk, as they might depend on code that does not exist anymore, for example.
How do you deal with this situation in practise?

A:

I would consider it the responsibility of the branch maintenance developer to merge the appropriate change into the current state of the trunk. There are several possibilities:

The code in the trunk has not changed and the patch applies without conflict.
The code in the trunk has changed and the patch applies, but with a manual merge needed.
The code in the trunk has completely changed and the patch cannot apply. The developer must evaluate whether the same defect exists in the trunk, and apply an equivalent fix if needed.

Cases 1 and 2 are the usual maintenance development paths. Case 3 is the case you are considering, where the trunk code cannot accept the maintenance patch in any form. If the developer cannot himself determine whether the same problem might exist in the trunk, then he should enter an issue into the issue tracking system. This issue would direct the trunk developers to consider the reason for the patch in the maintenance branch and whether the same defect might still exist. Entering a new issue for a possible defect in the trunk should be a last resort for the maintenance developer.
One benefit of having maintenance developers try to apply patches to the updated trunk is to increase their familiarity with the new code base. Eventually, they will run out of maintenance work and will need to work with the new trunk. Having at least a basic level of familiarity will be of great benefit.

A:

This is ultimately a question about team communication, rather than a simple branching/merging question.
The first step, as in all such cases, is realizing that you have a problem.  This is something that you've done.
Then, you need to alert the whole team to the issue.
Once you've done that, I think there are two different paths:

If the maintenance branches are used infrequently, say the released code is fairly mature and bug-free, you can decide on a code freeze.  Each developer must finish what he/she is working on by 32 Octember, and merge those changes back into the trunk.  The branches should then be either closed or frozen.  Then, work can continue in the trunk, and the new software can be released.
If there are frequent or urgent changes and fixes in the branches, this issue is more complicated.  There still needs to be a code freeze, or the trunk will be clobbered multiple times.  But here, developers still need to fix things in the interim and get them out to customers.  I suggest that every change in the branches after the trunk code freeze should be recorded in the bug tracking database (a must in every situation) with a special indication that this was fixed in branch N but not yet merged to the trunk.  This requires careful logging so that every relevant detail is remembered.
After the trunk is refactored, but before it is cleaned, buffed, tagged, and released, review the bug database, particularly the items fixed in the branches but not the trunk.  Are they still relevant?  Now is the time to change the code again, if necessary.  It may mean double work for a short while, but hopefully the code is much more maintainable now.
Once all the known issues are fixed, the new version can be released, and the old branches can be closed.

