Freezing for 2.18

[David Kastrup]

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