Re: branching stable/2.22?

[Jonas Hahnfeld]

Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb 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,

Did you mean to say "branching stable/2.20" (commit 0712559601)? While
some later commits might have made it into 2.20, I think there's still
more than the last few months.

> 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?

Yes, calling conventions and atomic replacement resulted in some
breakage, but the fixes in 2.21.4 and 2.21.5 seem to work (at least no
new complaints and reports on the mailing list that functionality has
been restored).

> * 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?

I fixed one wrongly referenced variable (TRANSLATION_FILES instead
of CHECKED_FILES) when updating the German web pages, but other than
that the instructions worked for me (who never did this before).


> * Move to gitlab: did all docs get updated?

Probably most, but maybe good to do another pass. One thing to consider
is issue verification (which hasn't happened for 2.21.2 and later
versions yet), but I'll start a separate thread about this.


> 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.

Adding Phil. I did a full test build of current master yesterday and it
worked fine with https://github.com/gperciva/gub/pull/80 in place.
With respect to wording, every 2.21.x is some kind of pre-release for
2.22. If this proposal gets consensus, I'd emphasize that feature
development is over, but I'll leave that to native speakers 😉

> * 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.

Sounds good to me.

signature.asc
Description: This is a digitally signed message part