Alan Conway wrote:
On Tue, 2008-08-05 at 13:50 +0100, Aidan Skinner wrote:
On Tue, Aug 5, 2008 at 1:41 PM, Gordon Sim <[EMAIL PROTECTED]> wrote:
Can you remind me the process that was agreed around branching?
What I recall us settling us on was "don't, not unless there's a
(customer money) gun to your head and it can't possibly wait until the
next release".
What I recall us saying is "don't until you really need one". We need
one if there is any post-M3 work going on during the freeze. I'm working
on clustering code that is well decoupled but still poses a risk of me
breaking the C++ broker. There may be others working on post-M3 work as
well.
I'd suggest we create an M3 branch and allow post-M3 work on trunk,
merging M3 to trunk as we go. The alternative is to use trunk for M3 and
create a post-M3-branch but that seems backwards to me.
I thought what we said was that in general during a project-wide
release, most everyone should be focused stabilizing trunk, and that if
someone really really needs to do new feature development during that
period, they should create a feature branch.
Doing feature development during a release creates more work for
everyone, so I tend to think a policy that discourages it, or at least
puts the merge burden onto those doing the new feature development is
quite sensible.
Ultimately the choice of how to branch comes down to who is doing the
merging. If we branch for M3 prior to stabilizing, we either need a
double commit policy (every commit needs to be both to the M3 branch and
trunk) or we need to do a wholesale merge once the release is done. The
latter option completely defeats your goal of integrating early and
often, and the former option is a huge burden considering that it takes
easily an hour to rigorously run through all the various java test
profiles prior to committing to just one branch.
If you flip things around and take a feature branch then its essentially
you (and probably me) doing merges from trunk whenever we feel the urge
to integrate, and we will be in a much better position to resolve any
merge conflicts since we'll be familiar with both the old code and the
new code.
So as someone who's likely to be participating on both sides of this, I
tend to think creating a feature branch is going to be much less work
all around.
--Rafael
