lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branching


From: Carl Sorensen
Subject: Re: branching
Date: 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
>> 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).

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.

Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]