I'm about to eat some humble pie, for which I'm going to get a lot of stick
for at work :)
After drawing about 1000 diagrams of various branching situations, I've
concluded (for what it's worth) that, in a complicated system, where you
want to make regular updates to production, but still keep these changes
untangled, then both approaches are....very similar.
Imagine the feature-branch strategy with a clean trunk, and several branches
leaving and then joining the main trunk at some point when they are
Then, turn it on it's side, so it points upwards, and grows from a new
horizontal trunk. The 'tree' is the release branch, and the trunk is
constantly being updated in preparation for a new release, which when it's
ready will become the second tree in this small wood.
A pure release-branch strategy doesn't work except for very simple cases.
But, a hybrid version works fine. And you get the benefit, as many people
have said, of being able to support multiple versions at the same time if
you need to. I think the downside may be that there are more branches
(probably only one more though - the [unstable] trunk) and more merging in
the long run (especially when you come to merge the release branch to the
trunk). But, as I said, I don't mind merging and branches.
The feature-based strategy supports only one version in production. If that
is acceptable, then I think this approach actually has less branches and
less merging to worry about in the long run.
I think this is correct. I'd be happy to recommend either approach now I
understand it in my mind (thanks Les, your last post helped me in this
Of course, I may be completely wrong and if people want to say so, I'm happy
to continue the debate. Otherwise, thanks to everyone for taking part. I'm
sure someone else will start it up again in a week or so anyway :)
>From: John Waycott <firstname.lastname@example.org>
>To: Richard Gundersen <email@example.com>
>Subject: Re: Branching strategy - Feature vs Release
>Date: Thu, 09 Nov 2006 07:54:29 -0700
>Richard Gundersen wrote:
>>Glad you are enjoying it :)
>>I like a good debate and I might be proven wrong. I'm applying my previous
>>experience to a new company where we don't have a strategy yet.
>>In my last job, the systems I looked after were used in 20+ countries. So,
>>one copy of the system, with lots of customisations. Each country would
>>have their own changes. Sometimes they would be cosmetic and low risk.
>>Other times, they would say 'Spain has a new law regarding X. The system
>>must support this law on 1st August 2007'. The application change cannot
>>however be released before then. It must be released at midnight, 31 July
>>2007, otherwise the system is operating illegally.
>>At the same time, Germany has another change. Theirs will take a long time
>>to implement so development must also be started now. But theirs must not
>>be released until 1st October 2007.
>>If all development is done on one trunk branch, then at some point I have
>>to tell Germany that because Spain MUST have their change, I have to
>>release their change too. I know what will happen - Germany will stop
>>using the system.
>>Using feature branches, when it comes to 31 July 2007, I just merge their
>>change into the trunk and release it. (OK, this would be done maybe a week
>>or two in advance for testing purposes). Germany isn't affected. Everyone
>This discussion is very interesting for me as well. We use Subversion for
>lots of different products: Internal web development, development tools,
>firmware that goes into manufactured hardware, outsourced software, PC
>applications, etc. Each of these require different policies and branching
>strategies. It boils down to what's best for your process; it's not that
>feature branches are better than release branches or vice-versa. Choose a
>strategy that works best for your process.
>We have some applications that have the same constraints as above;
>different countries require different features. We have a 'base'
>application that supports the common features. It uses a release-branch
>strategy. Each customer or country version then is on its own branch, which
>is more like a feature-branching strategy.
>To unsubscribe, e-mail: firstname.lastname@example.org
>For additional commands, e-mail: email@example.com
The new Windows Live Toolbar helps you guard against viruses
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Nov 9 23:28:48 2006