Handling Multiple Versions in a Single Project Team?

Posted by Mark Levison on Jun 02, 2008

Sections

Process & Practices,

Architecture & Design,

Operations & Infrastructure

Topics

Agile ,

Versioning

Tags

TargetProcess

Once you're team has released the first version of a product you're faced with the dilemma - how to maintain the first version while continuing to make progress on new releases. Facing this problem Michael Dubakov, CEO and Founder of Target Process wrote about their experience in "Should We Have Parallel Releases and Iterations in a Project?".

In this case Michael wanted fixes for version 1.0, ongoing work for 1.5 and new features being developed for 2.0. Do we have a single team because its only one project? Within that team do you assign some developers to release 2.0, others to 1.5 and steal time from Joe (the sacrificial developer) to fix critical issues in 1.0? For Michael the conclusion was to minimize waste and not work on 2.0. With all the developers focused on 1.5 we've reduced multi-tasking and are making decisions as late as possible (after all those must 2.0 features might not be must have by the time 2.0 rolls around).

In Steve Campbell's experience this problem is best solved when by including all the work (for all versions) in a single Sprint Backlog. The result any team member can pull a task (whichever the release) and work on it. Steve goes on to discuss branching strategies for this situation: either don't branch at all (using a runtime switch to differentiate versions) or branch only components that are undergoing a major rewrite.

Matt Swaffer, of Eclipse Software Systems Inc, uses a very different approach. His team doesn't ship patch releases, instead their goal is to maintain the stability of the trunk, then if a bug fix is required the customer is just invited to download the latest build. In addition they tag every release and in the event of a critical bug can go back to fix it. His ultimate goal weekly releases.

Switching to the issues around releasing several products from a single code stream, Kent Beck author of Implementation Patterns, talks about a two projects he's worked with that had to support seven customers. Each project had a fair amount of custom code in addition to the core logic. In one case they maintain separate code bases for each customer. When a new customer is acquired they clone the "freshest" branch and continue developing. As Kent notes they're sinking under the weight of their merges. On the other project a single binary is delivered to all customers in this case they found a way of making sure that only correct batch of custom code is run for each customer. In Kent's opinion the key difference is:

The key difference between the two is finding ways to defer binding. What I found was that this began by choosing a principle--we are going to have a single code base. This eliminated some design options, but plenty still remained. Another important principle is that in the first case we don't mind having some duplicate code. If it's clear how to eliminate duplication, we do, but we are willing to wait for clarity.

Finally John A. De Goes, of N-BRAIN says:

Branches are a form of waste and the goal is to eliminate them, to move to a single code stream, whose most recently released version is the only supported version, which is forcibly pushed to all installations on every release, with releases happening as frequently as possible (ideally, one release per feature/defect). All of which is made a lot simpler with SaaS.

• Older >