Re: branching

[Matthias Kilian]

[random notes from soneone who is *not* actively hacking on LilyPond,
so feel free to ignore it ;-)]

On Fri, Apr 15, 2011 at 03:29:52PM +0100, Graham Percival wrote:
> The reason that I'm pessimistic is that we racked up a huge amount
> of "technical debt" (i.e. bugs) during 2.11 and the early phase of
> 2.13.  I'm concerned that if we don't have regular releases, the
> unstable branch is going to accumilate bugs.

Well, I think I've written this a few months ago: (stable) releases
*must* happen more often (at least one or two times a year) if you
want to be able to cope with stable and unstable.

> I am also too tired to fight over it right now, but I also think
> that this is the wrong model of branching.  There's basically two
> ways:
> 1. keep master in a "ready-to-release" mode at all times; any
> serious bug gets reverted or fixed ASAP.  Unstable development
> happens on separate branches, which are merged to master when
> they're ready.
> 2. toss whatever garbage you want onto master, and make a "stable"
> branch where a bunch of poor suckers cleans up the branch until
> it's ready for a release.

1. is the way to go. Sure, it would put some pressure on people
working on big changes, which kind of sucks (it could even slow
down implementing cool new stuff). On the other hand, it enforces
smaller steps towards new features, which is good (easier to track
down regressions, easier to *understand* what's going on).

For maintaining a stable branch and cherry picking: the more stable
and master diverge, and the bigger the changes in master are, the
more difficult merges will be.

I'm note sure wether something like an "unstable" branch make sense
at all, because it may encourage to do big changes diverging from
master over a period too long to be mergable without problems later.

Just my 2p.

Ciao,
        Kili