Hi, In https://lists.gnu.org/archive/html/lilypond-devel/2022-05/msg00099.html, we talked about targeting the end of this year for the next stable release. That probably means branching around the beginning of September, right? I'd like to call for attention on the regressions we have <https://gitlab.com/lilypond/lilypond/-/issues/?label_name%5B%5D=Regression> as well as some other serious things that should go into this release: basically, (assuming branching in September) there is a month and a half left to take care of those. This is not all that long if not very short, especially since some people (like me) tend to be less active in August.
Dan and Jonas deserve thanks for having both worked on some of these recently. As you might have noticed, much of my work lately was also dedicated to fixing regressions. But there are quite a number of them remaining, and a they make a lot of work in total. So, if you're wondering what to contribute next, please consider putting in some time into one of these. Specifically, these seem significant to me: * Cairo anyone? What's the status of https://gitlab.com/lilypond/lilypond/-/merge_requests/913? Not really a blocker, but I thought the plan was to integrate Cairo in the official binaries for this stable release. * “Heisen-crashes on Windows with large scores” https://gitlab.com/lilypond/lilypond/-/issues/6361 A nasty and poorly understood GC problem on Windows, needs some tough debugging. * “GUILE 2.2 doesn't provide source locations” https://gitlab.com/lilypond/lilypond/-/issues/5992 Needs figuring out if executing Scheme code with `compile` is OK performance-wise and how to get it to display source location info. * “\markup \score in \paper can no longer have \layout block” https://gitlab.com/lilypond/lilypond/-/issues/6364 Needs investigating what broke with Guile 2 and its module system. * “No cropping when using lilypond-book-preamble include” https://gitlab.com/lilypond/lilypond/-/issues/6235 Needs either reverting to the old behavior or a Changes entry and a convert-ly rule. * “\bar creates a spurious staff” https://gitlab.com/lilypond/lilypond/-/issues/6341 * “Unterminated beam causes intimidating programming errors" https://gitlab.com/lilypond/lilypond/-/issues/6372 * “Changed behavior of staves with differing repeat structures breaks doc example" https://gitlab.com/lilypond/lilypond/-/issues/6373 Needs at least amending a doc example, but first checking that behavior changes are unlikely to be noticed often, and if not, add a Changes entry and/or a compilation warning if staves have different repeat structures. Again, if you have some energy, fixing one of these won't be wasted time. Thanks, Jean
