Re: branching stable/2.22?

[Jonas Hahnfeld]

Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup:
> Jonas Hahnfeld <hahnjo@hahnjo.de> writes:
> > Hi all,
> > 
> > I'd like to ask what it would take in principle to branch stable/2.22
> > and what others think about this.
> 
> I don't see that this is a good point of time.
> 
> There has been an influx of badly tested changes to the build system and
> directory setup and the web pages that has to stabilise and result in a
> workable version of LilyPond.  I don't see the point in branching a
> "stable" branch if there is so much in a destabilised state: you'd have
> to cherry-pick loads of stuff from the unstable branch as it comes in.

I fully agree and I should have been more clear that I don't expect the
branch to happen in the next week. The point was to find out what it
would take because just waiting for some unspoken condition to become
true is not exactly going to happen without some effort.

> > Personally I'm convinced that creating the branch and only picking bug
> > fixes from master is the only guaranteed way to stabilize.
> 
> Taking a look at Documentation/en/changes.tely, there has not exactly
> been a deluge of new features.
> 
> > Now you might say that there were only few unstable releases (AFAICT
> > there was 2.19.65 before branching stable/2.20). However, I think
> > there are already quite some user-facing changes and also the switch
> > to Python 3.  With Python 2.x being EOL since January, it's only a
> > matter of time until Linux distributions and BSDs want to drop that,
> > and it would be unfortunate if that put a (temporary) end to providing
> > LilyPond for their users. If we had release candidates or even a
> > stable version until then, it would definitely help.
> 
> At the current point of time, I see far too much focus on destabilising
> the code base that I consider a single-person(?) project of making a
> reasonably stable branch while the unstable branch is getting pounded on
> something that would work well.

Right, which makes discussion and a direction even more important.

> > The same can of course happen with Guile, but that situation has been
> > going on for years. Furthermore, it's at least possible to compile and
> > use current master with Guile 2.x, even if slower. In my
> > understanding, things are getting better but properly integrating byte
> > compilation is still a good amount of work that nobody could give a
> > deadline on.
> > 
> > WDYT?
> 
> While I see little point in making the quality of Guile-2+ support a
> showstopper, I don't see that the current pace of revamping the code
> base makes branching off a "stable" branch at this point of time a
> sensible proposition.  There just would be too much paralleled work in
> trying to get "stable" a sensible moniker.  The stable branch tends to
> see only rather superficial testing, and a large divergence from master
> would make its stability more a matter of wishful thinking than release
> engineering.

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