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