Re: branching stable/2.22?

[Han-Wen Nienhuys]

On Sat, Sep 5, 2020 at 10:52 AM Jonas Hahnfeld <hahnjo@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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen