How do I simultaneously work on version 1.1 and version 2.0?

Question

The situation: We're out of beta and version 1.0 has been released to several customer sites. Team A is already busy working on version 1.1 that will have incremental bugfixes and usability tweaks, while another team works on version 2.0 with large-scale changes, where the core of the product may have been completely redesigned. Now, most of the changes made for 1.1 will have to make their way into 2.0 at some point, and some of the bug fixes made in the 2.0 branch might in fact need to be scheduled for an earlier release. The problem is that since 2.0 has fundamental differences, no changes from 1.1 can be merged in without manual conversion, nor vice versa.

My question: What are the best revision control practises to minimise merge conflicts and duplicate work in this kind of situation? How can I ensure that my teams spend as little time and effort as possible on revision control issues, while still providing regular patches to customers?

Answer 1

One good way is to fix each bug in the stable branch and merge the stable branch into the development branch. This is the Parallel Maintenance/Development Lines pattern, and the key is to merge early and often. Merging infrequently and late means that the development branch is unrecognisable compared to the stable one, or the bug cannot be repeated in the same way.

Subversion includes merge tracking since version 1.5 so you ensure that the same change set is not merged twice, causing silly conflicts. Other systems exist (e.g. Git, Mercurial, Accurev, Perforce) that let you make queries of the type "what changes on branch A have not been merged into branch B?" and cherry-pick the fixes you need across to the dev branch.