lilypond-devel
[Top][All Lists]
Advanced

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

Re: Releasing 2.20


From: David Kastrup
Subject: Re: Releasing 2.20
Date: Thu, 08 Jun 2017 21:31:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Paul <address@hidden> writes:

> On 06/07/2017 04:34 PM, David Kastrup wrote:
>
>> tomorrow I am leaving for physical therapy.
>
> Hope it goes well David!
>
>> So how is it going to end up?  Barring objections, I'll probably branch
>> off a stable release branch early next week.  I'll have to see what to
>> cherry-pick into this branch as fixes proceed, and possibly what to
>> revert when it is not clear that functionality provided by recent
>> patches/changes can be considered stable in use and interface.
>>
>> I don't think that we should need much more than the 3-week maturing
>> period corresponding to the expected physical therapy duration.
>>
>> The alternative of releasing 2.18.3 since 2.18.2 does not even compile
>> using gcc-7 anymore is something I want to avoid.
>>
>> So I'd rather pitch for a timely release of 2.20.  There have been a few
>> critical bugs flagged, however.  I'll take a look at them eventually but
>> if someone else has a good idea...
>
> Sounds good to me.  I have a few things I'd like to get into the
> stable release, one way or another, if possible.
>
> - Some CSS edits for the docs that I started but havent
> finished/submitted for review yet.  I'll try to get that done in the
> next few days if I can.

Shouldn't matter a lot regarding stable/unstable but we should get the
bikeshedding finished by release time.

> - Might be worth looking again at issue 3884, either to just go with
> the initial patch for now, or try for one of the other approaches in
> that discussion?
> https://sourceforge.net/p/testlilyissues/issues/3884/

Ugh, looks like another ball I dropped.  I'll take to pencil and paper
some time tomorrow.

> - This doesn't really matter, but it might be worth renaming the
> "staffLineLayoutFunction" context property (which is not really about
> staff lines...) to something better, maybe
> "pitchToStaffPositionFunction" or pitchToStaffPositionProcedure"? (It
> takes a pitch and returns an integer indicating a vertical staff
> position.  It's used in note-heads-engraver.cc)

Well, discussion needs to have converged really well for changes to
preexisting conventions to get into stable: we don't really want to do
gratuitous changes that might get changed again or do not provide a
definite payback for the hassle.

-- 
David Kastrup



reply via email to

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