LilyPond 2.20 planning

[David Kastrup]

Ok, partly because of a lack of guidelines and getting stuck in my own
kind of stuff, 2.19 development has had a slow start.  There have been a
few niceties like pitchless rhythms, but overall no really significant
architectural changes have been done.

So we don't really need much of a stabilization period.  On the other
hand, we are getting into increasingly hot water regarding Guile 2
migration since distributions are fading out Guile 1, never mind that
Guile 2 has quite a few problems of its own.

So my proposal would be to try making a fast feature cut _except_ for
Guile 2 migration and focus on getting that done with.

It turns out that Guile 2 before version 2.0.11 (which is basically in
no distribution at all) has problems with curried definitions.  I'll
focus getting some workarounds in place, but if I don't find good
workarounds doing the trick, the main course would be:

Avoid using define-public et al (which includes several of LilyPond's
defining macros) with curried definitions in our own code base, and
people using it in external modules will get hit whenever the bugs are
still present.

Basically, blame-shifting where user code explicitly uses Guile
features, and workaround for ourselves (concerns probably few dozen
occurences at most).

The goal would be to crank out a Guile 2 using LilyPond in few months
and stall other developments yet again.

Yes, that's all very subfabulous, and the Guile migration, even if we
try our best, may well make the "few months" idea get a bit long in the
tooth, but I don't see good alternatives.

-- 
David Kastrup