On Sat, Sep 5, 2020 at 10:52 AM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > I think the real problem is that we don't know exactly how many > > problems there are that would be unacceptable in a stable release. So > > we need a way to coax people normally on stable releases to try out > > our current master, so we know where we are. Could we rename the > > current 2.21 as 2.22-RC1 or 2.21.90 and hopefully get some feedback? > > Well yes, that's the point of the whole thread, but I don't think we'll > get much feedback when continuing to break core functionality by usual > development. IMHO the bump to 2.21.90 (or some other high value) should > happen after branching, ie when it's really a release candidate. > We could of course have some smaller bump to advertise as alpha while > still working on master, but I doubt that would help much without some > kind of freeze... > > To reiterate the initial question: What would it take to get there? In > my opinion, that's equivalent to asking about critical issues that need > large changes to fix them.
I am not aware of critical issues at the moment. (While the doc build refactoring has been disruptive, and still hasn't completely stabilized, it doesn't affect end-users directly.) I read over the commits with potential end-user impact since branching 2.21, and got the following list of things to consider: * lots of changes to GS calling conventions updated; changes to default fonts? This has lots of area for unexpected interactions between platforms (windows!) and GS versions. At the same time, we control the GS version through GUB, right? * General: C++ changes triggering segfault due to optimized out GC references. We are probably well covered, though, because we run GL CI often; we haven't seen flakes recently, have we? * New output backend calling conventions may break user-supplied stencil expressions. This should probably be documented better in changes.tely. Also, I would like to hear from Scorio about the new backend API (ly:make-paper-outputter) before we commit to it in a stable version. * We have a lot of coverage for the Python3 migration for lilypond-book, musicxml2ly, and midi2ly, but what about other scripts? * Doc build rewrite: is the translation tooling working correctly now? * Move to gitlab: did all docs get updated? Here is my proposal for how to go ahead: * we build a 2.21.6 from master, and announce it widely as a 2.22 pre-release version. * we institute a X week freeze; during the freeze, we only merge - fixes for regressions - updates to the documentation - cleanups with no functional changes, with little risk (ie. refrain from build system changes, for example). * after the X week freeze, if we still have open regressions, we tack on another few weeks of freeze to fix them. * if there are no regressions left, we branch stable/2.22, and release a new pre-release. X could be up for discussion, but 3 or 4 weeks seems long enough to gather some feedback, but short enough that experimental/feature work should not be affected. The objective of the freeze is to focus developer energy on fixing regressions rather than causing new regressions. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
