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: Sat, 16 Apr 2011 13:04:16 -0600



On 4/16/11 12:50 PM, "Han-Wen Nienhuys" <address@hidden> wrote:

> On Fri, Apr 15, 2011 at 11:29 AM, Graham Percival
> <address@hidden> wrote:
> 
>>> The beauty of branching off is that nobody needs to hold off anything.
>>>  You just continue to put stuff in master (2.15.0), and cherry-pick
>>> whatever needs to go to 2.14.
>> 
>> I am pessimistic about this, but let's ask for volunteers.  Who
>> wants to cherry-pick stuff?
>> 
>> 
>> 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.
>> 
>> 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.
> 
> We are doing this, with the ready-to-release criterion being the
> regtest passing.  I propose we stick to this schema.
> 
> My proposal is that "ready-to-release" still is not strict enough for
> stable, so 2.14 version should be coming from something which moves
> slower than the master branch.

So does this mean we need three branches?

stable  (currently 2.12.x)
stable beta (currently stable/2.14)
development (currently 2.13.x)

stable beta and development should pass regtests.

stable beta will be ready-to-release when there are no critical bugs left.

After some  publishing of stable beta with no new critical issues, stable
beta will become stable.  At this point, stable beta will be the release
candidate for the next stable version.

Any patches that don't eliminate old syntax and don't break regtests can be
cherry-picked onto stable beta.

It seems to me that we ought to have three releases available:

stable -- demonstrated to work properly
stable beta -- all syntax from stable works, passes regtests, but not
demonstrated to be critical regression free.  Should be acceptable for
general release, but not for production work.
development -- passes regtests.  Recommended for developers and adventurous
users, but possibility exists for syntax changes.

Does this seem feasible?

Carl

> 
> --
> Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel




reply via email to

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