Path to LilyPond 2.18

[David Kastrup]

Hi folks,

since the call for stabilization/freeze more or less in April, there has
been quite a bit of work on finding and dealing with regressions.

The amount that have cropped up there is really sobering.  In particular
with regard to circular dependencies, it looks like a whack-a-mole game
where any change is followed by a series of badly understood regressions
and repair attempts.  That makes me less than confident that LilyPond's
architecture is developing in a manner that is suitable for scaling with
further growth of LilyPond's capabilities.  At any rate, this is the
architecture that is going into 2.18.

Another area of stabilization has been finding settings for the new
possibilities introduced in the 2.17 cycle, most of all the skyline work
from Mike, that are somewhat suitable for a stable release, creating
reasonably convincing output for untweaked input.

This appears to have led to reasonably well-looking results.

The stabilizing process has taken longer than anticipated (as always),
and there are still regressions getting discovered that are not suitable
for a stable release.  My own spacing work on issue 3330 (the last
larger piece I committed, to 2.17.19) cannot exactly be categorized as
fully compatible with the idea of a "freeze".  It did address several
issues and implements predictable semantics, so most of its effects have
a good chance of persisting for a long time, maybe more so than a
snapshot of the less consistent previous collection of behaviors.

While I was quick to suspect this chunk of code for every spacing
regression reported afterwards, it turned out that older changes were
responsible.  There is still some cleanup pending to account for some of
its effects, but that seems reasonably straightforward to do.

Keith has done quite a job hunting through past issue reports,
reevaluating and classifying some, and not least of all concocting fixes
for a fair number of them.  Trevor has done quite a bit of documentation
work together with several others.

We still have several regressions without a clear fix, and the overall
flavor is not really one of finality.  But we are in a state where
substantial or gamechanging improvements are not going to finish in a
reasonably short time scale.

So for better or worse, we need to start wrapping up what we are going
to call our next stable release.

I propose calling the next developer release 2.17.95 to send out the
message that finish-up work is called for: those translators who don't
have the resources for following all changes during a development cycle
_now_ really should try catching up.  We need to get the latest
regressions under wraps, and we need to get users trying and reporting
their experiences with the current version in order to get the rough
edges out and have a chance, where called for, to better tune the
default settings for new knobs to production-ready settings.

-- 
David Kastrup