Am Dienstag, dem 22.02.2022 um 16:55 +0000 schrieb Werner LEMBERG: > [First of all: Thanks, Jonas, for releasing 2.22.2 today!]
[Well, I didn't do this alone, Phil does most of the actual release procedure like editing the right files that both of us keep forgetting and things like that] > I guess most people like me lack the skills to give helpful comments, > so they stay silent. The only part where I can voice an opinion is > the following. > > > > Meanwhile, please take a look at reality: Linux distributions are > > > switching to Guile 2.2 for LilyPond, no matter what the state is > > > and what our documentation recommends. Debian attempted to > > > switch for the stable release 2.22.0 (that is now in Debian > > > stable) and we convinced them to stick to Guile 1.8 more-or-less > > > last minute. Arch Linux switched to using Guile 2.2 twice, but I > > > was able to convince them that they should wait. Gentoo has an > > > option to build with Guile 2, not sure if it's used by default or > > > up to the user. The package in Fedora continues to use Guile 2.2 > > > IIRC. > > > > > > What this tells me is that we get a split user community if we do > > > nothing. If we want to avoid that and pro-actively test and fix > > > issues, we have to switch *now* and lead the transition. > > Jonas, you are doing a wonderful job by working on the Guile 2.2 > transition. However, it seems to me that it will still take a > significant time until we have something that can be used for daily > work. Even if I don't fully agree, what's your take then on the real situation that I described? Isn't that even worse from a user's perspective? > Otherwise I could imagine to do the following. > > (a) Incorporate Guile 1.8 into the LilyPond tarball to produce > releases without fearing that distributions eliminate LilyPond > packages. > > (b) Produce development releases with Guile 1.8 for people in the (1) > group, probably with GUB. Recent MacOS users would have to use > MacPorts. > > (c) Produce development releases with Guile 2.2 for people in the (2) > group with Jonas' build system. > > I'm not sure how much of my suggestion can be automated to reduce > manual work on it. This would basically freeze the current status of doing releases with GUB - while I made sure the binaries with Guile 2.2 can be produced from a tarball, GUB assumes that it's the authoritative release tool. And (a) and (b) makes it necessary to keep GUB alive *and* precludes us from making progress for all the reasons I mentioned on Sunday and yesterday. Jonas
signature.asc
Description: This is a digitally signed message part
