[RFC] Transition to Guile 3.0

[Jonas Hahnfeld]

Hi all,

I hear LilyPond hasn't changed its Guile version since some time (more
than 18 months). So before we get too comfortable with the current
situation, let me propose to move to Guile 3.0. Below is a plan for
that switch, with a transition period to test the official binaries.
Last time, when going from Guile 1.8 to version 2.2, the switch had to
coincide with moving away from GUB. Between Guile 2.2 and 3.0, we could
in principle support both versions for a longer period. However, I
personally think that a full transition and dropping support for Guile
2.2 is the more reasonable approach: It will reduce testing
configurations (both for development and user reports) and hopefully
enable some future cleanups in the code.

Step 1: Officially support Guile 3.0 and add optional CI testing
I opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 to
add some compatibility with earlier versions of Guile 3.0 and then
implement detection support in configure. It also creates Docker images
and adds optional CI testing, as we had it for the transition to Guile
2.2.

Step 2: Release unstable version and test new binaries
https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 has the
changes to produce official binaries with Guile 3.0(.9). For Windows,
it currently relies on a number of patches that I also sent upstream.
In some sense, the situation is not worse than Guile 2.2 where we also
had patches. Or arguably it is better because there is the possibility
that the changes will be merged upstream...

I propose to not merge the changes for our binaries immediately, but
instead produce an additional set of binaries with the next unstable
release. That way, users can test on all platforms and make sure the
setup works. Again, this is similar to what we had in LilyPond 2.23.6
when switching to Guile 2.2.

Step 2a: Assuming this testing goes fine, I would like to backport the
changes from the first step to stable/2.24 and release a new stable
version. The idea is that distributions wanting to drop their package
for Guile 2.2 can switch LilyPond 2.24 to Guile 3.0. Note that the
official binaries will stay Guile 2.2 for future bug fix releases, it's
only about officially supporting the later version. However, we also
have to see how the situation develops with Ghostscript 10.02.1, so
let's postpone discussion on this topic for now...

Step 3: Switch to Guile 3.0
Afterwards, we can
merge https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and
then remove automatic detection of Guile 2.2 from configure. It would
still be possible to build LilyPond with GUILE_FLAVOR=guile-2.2 for
some limited time, until ...

Step 4: Remove compatibility code for Guile 2.2
This can happen after we made one or two releases with only Guile 3.0.

Step 5? Move to Ubuntu 22.04 for testing and bump requirement to Guile
3.0.7? Then we could remove some more compatibility code, but let's
discuss this at some later point.

Please let me know of your comments!
Jonas

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