lilypond-user
[Top][All Lists]
Advanced

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

Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision)


From: David Kastrup
Subject: Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision)
Date: Wed, 01 Aug 2012 16:42:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Wed, Aug 01, 2012 at 03:21:34PM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> 
>> >> If it is non-operative, it should be either made operative or removed.
>> >> There is no point dragging it along as purely dead weight we should not
>> >> be using.
>> >
>> > Sure, patches appreciated.
>> 
>> You know that this comes across as "In my opinion nobody but the foolish
>> person asking for this should think of working on that problem."?  I am
>> staking out the requirements I need to get the appointed job done.
>> Unless you have some reasonable suggestions how to get around those
>> requirements, I see little point in discouraging others from helping
>> with them.
>
> I apologize; you are quite correct.
>
>
>> > I'm missing something.  What's wrong with this scenario: - I
>> > release 2.15.42 today or tomorrow.  - you branch stable/2.16
>> > from that.  - in a week I release 2.17.0.  - you do whatever
>> > you want with 2.15.43, 2.15.44, etc, until you reach 2.16.0.
>> > Other than probably having no syntax changes because I really
>> > don't know how that can be juggled.
>> 
>> There will be no syntax changes in the 2.16 branch, at least not
>> of the convert-ly kind (one reasonably established syntax to a
>> different intended one).
>
> Shall I go ahead and do 2.15.42, then?

It is overdue anyway.  I won't promise that there will be no need for
2.15.43: I think there are some things I feel worth sorting out before
branching.

I'll take stock after 2.15.42 and, in case I decide I need stuff done,
create/mark the respective critical issues.

In any case, I guess after branching we'll split into 2.15.90 and 2.17.0
as the next prospective releases.  It would seem that those numbering
schemes will be supported by existing tools and would mostly meet the
requirements for the post-branching versioning.  I am not particularly
happy with "final version updates/minimal convert-ly just happen on
Graham's computer, not in prereleases", but that appears to be what we
have to work with.  It is not clear to me when the final snippet version
updates on the 2.17 aka master branch will be happening, whether
synchronized to the 2.16 release or not.

-- 
David Kastrup



reply via email to

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