branching stable/2.22?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

branching stable/2.22?

Jonas Hahnfeld
Hi all,

I'd like to ask what it would take in principle to branch stable/2.22
and what others think about this.

Personally I'm convinced that creating the branch and only picking bug
fixes from master is the only guaranteed way to stabilize. 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.
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?

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: branching stable/2.22?

David Kastrup
Jonas Hahnfeld <[hidden email]> 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.

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

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

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: branching stable/2.22?

Jonas Hahnfeld
Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup:

> Jonas Hahnfeld <[hidden email]> 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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: branching stable/2.22?

Han-Wen Nienhuys-3
In reply to this post by Jonas Hahnfeld
On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld <[hidden email]> wrote:

> I'd like to ask what it would take in principle to branch stable/2.22
> and what others think about this.
>
> Personally I'm convinced that creating the branch and only picking bug
> fixes from master is the only guaranteed way to stabilize. 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.
> 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?

I think that both Python 3 support and usable (if imperfect) GUILE 2
support is a strong argument for releasing a new stable version soon.

I've been working on the build system (obviously), with in the back of
my mind having a build that is no longer recursive, but that work
could be paused for a bit while we prepare for releasing a 2.22.

Is there a list of problems in the current master that have to be resolved?

We could also consider a freeze for some time period (eg. 1-2 months),
to allow the master branch to stabilize, before we cut 2.22.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen