Ok folks, it is this time of the year again: I am trying to make myself unpopular.
2.16 is growing old. Now you might go "Huh?", but here are salient points: a) \override/\revert syntax is increasingly becoming an issue on the mailing list. There are also related commands that are affected. b) footnotes in 2.16 have somewhat different syntax and quite more restricted behavior. (Non-markup) footnotes to lyrics would likely requiring adding footnote engravers to Lyrics contexts and stuff. c) the Skyline stuff is also nice to have and addresses a number of shortcomings d) documentation is quite better. e) not a must-have, but a bit of a selling point: \tuplet f) lots of bug fixes g) other enhancements "lots of bug fixes" could be addressed by backporting. However, we are talking about "lots", and some are related with functional changes. So backporting implies a lot of work, and I think we have lost the connection to where one can do a good selection of backport work. So I want to see 2.18 soon. That means we need to stabilize work that has already been done and cut down on experiments in the master branch. Stabilizing means more or less accepting the current feature set, and making sure it works as intended, is a useful combination of things, does not offer interfaces which are sure not to survive into the next stable version, and most of all, is properly documented to the user. It also means that commits of the "this really does nothing, but it prepares the ground for $xxx, and I don't know just where this is going, so quite a bit of it might be changed into something different yet" should happen in a branch. Actually, I am of the opinion that most of these changes should happen in a branch anyway. A "commit" implies commitment, and if one has taken a bad path, redoing it is much harder if the dead end has already ended in the main code base. At any rate, I'd like to aim for 2.18 at about the end of May, and getting into serious freeze at the end of April. A focus on bug fixes, in particular bugs introduced in the 2.17 development cycle, should take priority. Fixing long-standing bugs hard to address should likely be left for early 2.19 and/or be done in a branch. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
