[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 15 Apr 2011 13:40:20 -0600
On 4/15/11 12:32 PM, "Matthias Kilian" <address@hidden> wrote:
> [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
>> 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).
This is what we've been doing for the past 4 months or more.
How do we define the difference between "stable development" and "unstable
development"? It seems to me that "stable development" means we pass the
regtests -- we've been doing that for at least a couple of years. But we
still end up with regressions when users test the code beyond what the
developers have tested.
As long as we have a policy that any regression will delay a stable release
for two weeks, it seems to me that we *must* stop adding features in order
to get a stable release. We can't prevent unintended regressions.
OTOH, if the standard for "ready-to-release" were "make check succeeds and
no segfaults have been identified", then we've been ready to release a
stable version for a long time now.
Re: branching, Matthias Kilian, 2011/04/15
Re: branching, Trevor Daniels, 2011/04/16
Re: branching, Han-Wen Nienhuys, 2011/04/16
- Re: branching, (continued)