[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 |
Hi,
(Sorry about the strange reply style.)
On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld <hah...@hahnjo.de> 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.
>
> WDYT?
[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 lilypond.org, 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?
Cheers,
Jean
- branching stable/2.22?, Jonas Hahnfeld, 2020/08/23
- Re: branching stable/2.22?,
Jean Abou Samra <=
- Re: branching stable/2.22?, Dan Eble, 2020/08/24
- Re: branching stable/2.22?, Jonas Hahnfeld, 2020/08/24
- Re: branching stable/2.22?, Jean Abou Samra, 2020/08/24
- Re: branching stable/2.22?, Jonas Hahnfeld, 2020/08/24
- Re: branching stable/2.22?, David Kastrup, 2020/08/24
- Re: branching stable/2.22?, Jean Abou Samra, 2020/08/24
- Re: branching stable/2.22?, Jonas Hahnfeld, 2020/08/25
- Re: branching stable/2.22?, Jean Abou Samra, 2020/08/25
- Re: branching stable/2.22?, Jonas Hahnfeld, 2020/08/25
- Message not available
- Re: branching stable/2.22?, Jonas Hahnfeld, 2020/08/25