Re: 2.16 release candidate 3 imminent

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 1/21/12 9:45 AM, "Graham Percival" <address@hidden> wrote:
>
>>On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
>>> I would very much prefer the work on Issue 2240 (aka 2070) to make it
>>> into 2.16.  It is a significant API change that should not occur during
>>> a stable release series, and it paves the way for making the music
>>> function work continue smoothly enough that backporting further
>>> enhancements into a stable 2.16 series would be feasible.
>>
>>IMO, significant API changes should not happen right before a
>>release.  Version numbers are cheap; why not have 2.18 in March
>>2012?  Backporting is a huge hassle.
>>
>
> Earlier, we expressed a need to have stable mean *stable*, i.e. no
> syntax changes necessary for some period of time.

Strictly speaking, this is not a syntax change.  If you write LilyPond,
no Scheme, the output should be the same.

I have actually found out that I promised too much about string numbers
appearing on isolated notes: since the string number events _are_
listened to (likely by the tabstaff engraver team), the rhythmic music
iterator _does_ broadcast them instead of leaving them as articulations.

I certainly would have been more than happy to have that inconsistency
abolished.  The way to do that would be to _stop_ the tabstaff engravers
from listening to string events and instead have them look in the
articulations for them.  If the string events become unlistened to, the
rhythmic music iterator will leave them in the articulations.
Alternatively, make a listener/engraver for per-chord string indications
(which, like fingerings, can be typeset with less need to keep them
close to the notehead).

> We wanted stable versions to have a significant lifetime so things
> like LilyPondTool and Frescobaldi didn't need to always keep changing.

I don't think they will be affected unless they do Scheme juggling.  The
one thing that _will_ be affected is XML output.

> If we still want to have that policy, I believe that subversion
> numbers are cheap, but stable version numbers are expensive.
>
> I think we'd be best to try to get this into 2.16.

And it definitely needs to be in a prerelease for that.  If the
prerelease makes it obvious that this won't work, it will have to be
backed out, something which I would find rather unhappy (since it would
mean that parts of the music function syntax changes that belong
together logically would be spread across two stable releases).  If you
take a look at the stats, you'll find that apart from the implementation
of the rhythmic music iterator (which is rather boilerplate), most of
the changes are _reductions_ in size.  In particular the parser.

It will also make the programmer's guide simpler.  I am starting on that
now.

commit 0e9b4d86388b83bfbd217b0d77d6759f2ef81cef
Author: David Kastrup <address@hidden>
Date:   Thu Dec 1 18:32:15 2011 +0100

    Don't wrap EventChord around rhythmic events outside of music lists.

 9 files changed, 212 insertions(+), 222 deletions(-)

commit 10c40a07236febc9279a5faadbcdc15dc3bb1c82
Author: David Kastrup <address@hidden>
Date:   Sat Jan 21 14:24:01 2012 +0100

    Let \relative run through articulations for the sake of pitched trills

 1 files changed, 1 insertions(+), 0 deletions(-)

commit 84144db390bac765fcd0e80403b548ca4e90a59f
Author: David Kastrup <address@hidden>
Date:   Fri Jan 20 21:38:09 2012 +0100

    Define a post-event music type and let post-event? and ly:event? use it.

 5 files changed, 37 insertions(+), 68 deletions(-)

commit c4760f3c4a5ec896231e285363c8f10e59a07c53
Author: David Kastrup <address@hidden>
Date:   Thu Jan 19 18:58:38 2012 +0100

    Fixes to Rhythmic-music-iterator

 4 files changed, 38 insertions(+), 9 deletions(-)

commit efb9bc79e3714ce06ef48b148850de29625ddb18
Author: Mike Solomon <address@hidden>
Date:   Wed Jan 18 20:12:13 2012 +0100

    Implements rhythmic-music-iterator

 3 files changed, 109 insertions(+), 0 deletions(-)

-- 
David Kastrup