views:

274

answers:

3

In my current project I have to decide which technique to use when branching. I have two options (we'll assume that we already have decided to develop in the trunk):

Version branches

Make a branch whenever a new version is put on the test machines and tag it like "release0.1". Bugs are fixed in this branch (and then merged to the trunk of course) and when this release finally goes live it's tagged "release0.1.1". This leads to having a branch for every major version and a tag for every minor version. If a bug has to be fixed in the live-version, it's fixed in it's appropriate branch and then merged down to the trunk.

Version promotion

Have only three branches "trunk" (for development), "test" and "live". When a version is put on the test machines, the trunk is merged (promoted) into the "test" branch, bugs are fixed in that branch and when the version is released, the "test" branch is merged into the "live" branch. If we find a bug in the "live" branch, it's fixed there and then merged down to the trunk.

What are the pros and cons of these two philosophies? What are your own experiences? Are there any other - possibly better - methods available?

+3  A: 

It depends on your maintenance policy.

If you choose to maintain more than the latest release (XP in parallel to Vista for instance), version branches is a better choice.

mouviciel
Exactly my point. If you need to maintain multiple "live" versions of the product at the same time, you will definitely get most out of the version branches.On the other hand - if the product you are developing is a hosted service (like StackOverflow or Twitter for example), the "version promotion" starts making a lot of sense as well.
Roland Tepp
A: 

From my experience version promotion has much smaller overhead on merging changes from different branches and trying to remember what was fixed on which branch, etc. so whenever possible I prefer to work this way. Unfortunately, if you use version promotion it is often not possible to do small quick fixes on the released version (because there are big chunks of code checked in to the "test" branch) -> so we and up having version branches.

To sum up I think (for me at least) usually the best way is to do something in-between the two - do all development on trunk (main branch), tag all builds/releases, and create a version branch only if needed (e.g. there is a critical bug in production, and there are changes in trunk that can't be released).

Grzenio
A: 

In my opinion, the two are note exclusive.

The version branches mecanism is needed if you have to maintain different RELEASED versions. But I think it is a best-practice to always prepare a branching point (depending on your gestion version system) after releasing a version.

The "promotion" mecanism is needed if you have to release test version. This is usefull if you have, for example, a validation team distinct to development team and/or large team where development goes fast. In these cases, you need a specific branch to stabilize the next "stable" release while trunk stay "unstable".

Guyou