Re: Stable release proposal

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> Carl, Although I'm not a current developer, I'd like to comment.
>
> In general I agree, but with the caveats below:
>
> Carl Sorensen wrote Tuesday, January 17, 2012 1:27 AM
>
>
>> So after hearing from most of the currently-active developers, I think a
>> reasonable goal for 2.16 would be:
>>
>> 1) Work through the outstanding issues involved in issue 2070  -- Don't
>> wrap EventChord around all note heads.  This is probably a big issue, but
>> I think with David working on it it will happen quickly once we work
>> through the issues.  To me, this is the biggest outstanding issue, but I
>> think it will be worth tackling.
>
> This looks like a big undertaking.  I think we need to be advised
> by David about this.  Well worth doing if he is agreeable and
> confident.

It depends on the progress we are able to make here.  This changes the
internal representation of music expressions (usually taking less space
than before and better matching the expectations for a given input).
That means that programs working on music expressions will get to see
different input.  It is not a change to make in a stable release series.
It forms an excellent complement to the work I have been doing on the
parser groundwork, and paves the path for continuing with it.  But it is
slated as a change of internal representation, and if it does not get
into 2.16.1, the next opportunity is 2.17.  I would be loath to miss
this opportunity to tie the groundwork I have been working on into a
more consistent whole than it can currently be done, but if this does
not make it at least into early release candidates, it does not belong
in 2.16.

>> 5) Remove translations if they are not updated to 2.16.  The 2.14/2.15
>> manuals can be used if desired.  Having non-updated manuals removed may
>> serve as an incentive to get them all translated.
>
> I'd prefer to see all translations carried forward, even though they
> are incomplete, much as we carry forward the English documentation,
> even though much of it is incomplete.

We have "translation of committish" in the start of translated files.
Maybe we could use this information for automatically generating
(localized) messages "warning: this section may be outdated.  It
corresponds to the English version from xxxx-xx-xx.  The English version
has last been changed on xxxx-xx-xx.".  Possibly with hyperlinks.

>> B) Guile 2.0.  I think there's enough going on with Guile 2.0 on
>> their side (adding local-eval back in) that we shouldn't push this
>> for the next stable release.
>
> Leave out.  This looks as if it needs a long run in.

Our current code does not depend on local-eval.  The code would be
cleaner, faster and more compact if it did, but not breathtakingly so.
The "local-eval" implementation that is likely going to end in 2.0.4 is
not independent from the other Guile code, so we don't have the option
of just taking it as a fallback for versions 2.0-2.0.3.  I don't
particularly like our current code, but I don't see that it makes sense
to make Ian's life even harder by requiring local-eval at the current
point of time (meaning 2.16).  Even though I am not happy about the
message this sends to upstream Guile who currently invest a lot of
thought and effort into bringing local-eval back.

If we reach a decision of "2.16 will be Guilev1 only" at some point of
time, I might be tempted to change the embedded LilyPond code back into
using local-eval in the release branch once 2.16 has been branched off
from master.  It would be, well, more stable and have less overhead for
#{ ... #}.  But master itself should not do Guilev1-only changes
deliberately.

-- 
David Kastrup