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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
