Refactoring and concurrent development branches

Question

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?

Answer 1

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:

1. The code in the trunk has not changed and the patch applies without conflict.
2. The code in the trunk has changed and the patch applies, but with a manual merge needed.
3. 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.