[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branching stable/2.22?

From: Jean Abou Samra
Subject: Re: branching stable/2.22?
Date: Sun, 23 Aug 2020 23:44:44 +0200


(Sorry about the strange reply style.)

On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld <> 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.

Maybe we could try to release 2.20.1 with Python 3?

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

[Han-Wen] 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.

Why Guile 2? If it's still imperfect and slower, we don't want to make it the 
default in the binaries at, do we? So how will the situation be 
different from 2.20? Sorry, I must be missing something obvious here... I don't 
understand you.

At any rate, Python 3 support is great, but the scripts are fragile at the 
moment. This is clear from the tracker and the bug-lilypond list. Our Python 
scripts still need fixes in the way we distribute them, plus encoding-related 
issues (I'm planning on tackling the latter point in a short period at the end 
of August, but who knows what that will reveal).

[Han-Wen] 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?

Problems are basically popping every week (e.g., info installation, translation 
tools, etc.). You're fixing them every week, which is really great, but before 
creating a release branch that is devoted to stability, I think we need a 
couple months to see what new problems appear, don't we?

We have unstable releases to publish new features and get testing. In my 
opinion, stable releases should really focus on stability, there's no need to 
rush because of Python 3 and Guile 2.

At least four areas are currently under flux: Python scripts, the build system, 
Guile 2 support, and fonts (Owen's project), and I don't see that master is 
coming any close to stability. I think we are better with focusing on these 
areas as long as they still require substantial attention, so as to get a 
stable and nice LilyPond 2.22 in a timely manner. You derecursify the build, 
David completes his stack of rather extensive purportive changes, Owen merges 
the GSoC branch, etc., and only then it'll be time to care about LilyPond 2.22.

Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup:
> > 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.

[Jonas] I fully agree 

... and so do I (for what my opinion's worth, really) ...

[Jonas] 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.

What about scheduling the release?

While I do know that "Grass doesn't grow faster when you pull on it.", I would 
definitely like having a defined point in time where the stable release is to 
happen, so that everyone can focus on bug fixes before it happens. Sure, we 
aren't going to get agreement in a second about the date (even if not more 
precise than a month), but to me, having this talk now is preferable so as to 
give LilyPond development a tempo. To say it with other words, we've got a 
score to play; arguing about the tempo is better than starting the piece with 
different tempi.

As sort of a shot in the dark, how about planning the 2.22 release for May 
2021, for example?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]