On Thu, 2008-06-26 at 12:08 -0400, Rafael Schloming wrote:
> I think in general branching tends to get messy more quickly and easily
> than people expect, and this is true even if you're someone like me who
> always expects branches to be messy.
Amen brother.
> Given this I tend to favor a release model that avoids branching unless
> absolutely necessary. Something along the lines of every n months we do
> a release by stabilizing trunk to the point where it meets our release
> criteria, and then make a release branch at that particular snapshot of
> trunk.
I like this, let me elaborate. I'll use M3.0, M3.1 etc as examples
because M{X}.{Y} confuses me :)
Before every release we lock the trunk for release stabilization. When
we ship, we create an M3.0 tag from trunk. We proceed fixing bugs &
improving things till our next release period, at which point we lock
the trunk again & make an M3.1 tag.
Now somebody wants to do a major refactoring or new features for version
4.0. Before they start we tag the trunk M3.2-base. We continue with
fixes & new 4.0 features on trunk. If all goes well we don't have to do
a 3.2 release until we're ready to release 4.0. Lock the trunk, ship &
tag M4.0.
Note so far we have major & minor updates with 0 branches :)
The only time we _need_ to branch is if we want to do a 3.2 release
*after* the M3.2-base tag was created. That could be for 2 reasons:
- 4.0 takes too long, we decide to do a 3.2 release first.
- we decide to issue a 3.2 fix release for users of M3.1 that can't
upgrade to 4.0 immediately.
In either case we branch M3.x from M3.2-base. Changes for M3.2 are
merged to M3.x first, then to trunk OR back-ported (not merged) from
trunk. When we are ready to release M3.2 we do the same thing but this
time using M3.x as our "trunk" - we lock M3.x, stabilize and tag M3.2.
>From now on any further M3.x releases are done on the 3.x branch, so
they are isolated from the trunk.
So except in the (hopefully) exceptional cases above, we *never need a
branch*.
> I would also say that when bugs are reported against a particular
> release, we should as a general rule fix them on trunk and encourage
> users to upgrade to the next release. I would say only on a case by case
> basis should we backport specific fixes to any release branch. I think
> this policy avoids unnecessary branching/merging, and also ensures that
> release branches are kept stable unless there is good reason to disturb
> them.
Agreed. If there is no next-major-version work on trunk we never need a
branch, everything goes on trunk and into the next point release. If we
have started next-major-version work (big refactorings etc.) then we
have to make a choice: we can continue on trunk and risk having to
back-port the changes if we do need another point release OR we can
start the 3.x branch and merge to trunk.
For small fixes in areas that have not diverged much between trunk & 3.x
I'd be inclined to put them on 3.x, with everything else on the trunk.
>
> This model does close down trunk for radical new feature development
> when a release occurs, but I would hope that the need to do radical new
> feature development during a release is an exception, not the rule, and
> in that case I think it's reasonable for the feature development to be
> done on a branch. Certainly if no such feature development is happening
> it would be nice to avoid the additional merge overhead of branching
> *before* stabilizing.
Agreed. If someone wants to start 4.0 work while a 3.n point release is
going on, they create a 4.0-future branch, do their new work on that and
merge out stabilization changes from trunk. When the 3.n release is
closed, we lay down the 3.n+1-base tag and merge 4.0-future into the
trunk. At that point we can delete the 4.0-future branch and continue on
trunk.
