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

I would probably rely on an issue tracking system for this purpose, and make sure to tag each change that needed to be brought forward into the trunk code. You can then ensure that check-in comments for each change reference the relevant issue, and are clear in expressing the intent of the code change so that it can be easily understood when trying to re-implement in the trunk.

Answer 2

The article here (Day-to-day with Subversion) mentions that one method is to constantly update version 2 with data from the version 1.1 build. In the article, the guy says to do this every day.

The part you'll want to read is titled "Waiter, There's a Bug in my Trunk!". It's about halfway though the article.

Answer 3

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.

Answer 4

Merge early, merge often, and make sure that QA on the mainline knows and regresses/verifies the defects fixed in each patch of the maintenance releases.

It's really easy to let something slip out and "unfix" a bug in a subsequent release, and let me tell you, customers don't care about how complicated it can get to manage multiple branches -- that's your job.

Make sure you're using a source control system that supports branching and merging (I've had experience with Perforce and SVN, and while Perforce is better, SVN is free).

I also believe that having a single person responsible for performing the merges in a consistent manner helps ensure that they happen regularly. It's generally been me or one of the senior people on our team.

Answer 5

The way we handle this at my work is to keep the trunk branch as the most cutting-edge code (ie, 2.0 in this case). You create a branch for the 1.x code, and make all your fixes there. Any changes to 1.x should be merged (manually, if need be) into the trunk (2.0) branch.

I would then insist that 1.x developers make note of both the revision number for the 1.x commit and the revision number for the 2.0 merge in the ticket for that bug. That way, it will be easier to notice if anyone forgets to merge their changes, and the fact that they have to keep track of it will help them remember.

Answer 6

Pretty much what everyone else has said, but I figured I would toss in my experience with handling development in multiple branches using SVN

With our main product, we have the need to simultaneously develop in 2+ versions at the same time.

I originally used the main trunk as the "main development" version, with tags used for each actual release. Branches were used for substantial development efforts for a new feature set. Then later, when we started working on 2, 3 and 4 releases at a time I started using a branch for each revision.

Since I maintain the repository and also handle pushing QA builds, I make sure to do "rollups" each morning - which consists of merging changes up the tree starting with the lowest currently active branch. So I end up merging changes from 1.1 into 1.2, which is merged into 1.3 with any other changes from 1.2 since the last merge, etc.

When I commit, I make sure to always comment the commit with something like

merged 1.1 rev 5656-5690

It can be a bit of a pain, but it works :)

Answer 7

One key point is captured in this picture from The Build Doctor: only merge one direction.

Answer 8

To answer that specific question many developers have switched from Subversion to Git. Checkout github.com.