What are the benefits of "Staircase" branching?

Question

Hi,

I've encountered a project where we use staircase branching. To clarify, this is the approach where code is branched for development and when the development completes, rather than cutting back to a trunk/main line, the dev branch is designated as the live code set and a new branch is taken from it. This continues ad infinitum.

I personally prefer the cut back to a trunk approach to maintain one single "live" codeset. However I am wondering if there are any compeling benefits to the staircase approach.

Thanks, Tom

Answer 1

There are a couple of (potentially minor) benefits to this approach.

The most compelling benefits arise from the lack of need to merge changes back into the main branch. This makes it easy to keep a branch (the old "trunk") for the version where you branched, as well as requiring no effort on the dev branch to continue on. In reality, this is no different than having one live trunk and tagging or branching out for a release, though - except that you "move" your development instead of moving your tagged branch. This can make it easier to maintain clean branches with less effort, since there's no need to "tag" a new branch for each release - it just kind of happens automatically. This is a minor timesavings, though.

In my experience, though, there is one potential disadvantage. I've often found that this approach often makes it easier for developers to accidentally break binary compatibility in libraries, since you're always working on a development copy, and each "release" is a separate branch from that. Since there's no effort required in merging back to a trunk, it can be easy to accidentally break an API. This isn't a major concern IMO, but is something to be aware of, since there is no effort during the merge process (which seems to be where most of these mistakes are often discovered).

Answer 2

I believe it's a way to make it easier to roll back, and a little clearer the differences between versions. It's also easier to continue developing a previous version (for instance, having a version for developers and a version for designers).

I myself prefer the other approach with tags indicating the checkpoints. I use git, and the process of branching and doing this kind of stuff is really well built with it.

Answer 3

Right from the start of the first stair, you are in the same position as were when developing the first release. this is it, no late decisions about what to move back into the main trunk. The build from the stair is your latest candidate.

Penalty, if lots of change and fix in original you have merging up to do, and that might be disruptive. I'm guessing that there may be a break-even point when rate of change for the new release and rate of patch in the old make staircase suboptimal.

Answer 4

This method will bite you in the derriere the moment you want to create multiple branches and develop against them concurrently. Merging back to the trunk allows you to have parallel branches and easily bring them together one branch at a time.