lilypond-devel
[Top][All Lists]
Advanced

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

Re: [RFC] Updating the CI image and bumping requirements


From: Han-Wen Nienhuys
Subject: Re: [RFC] Updating the CI image and bumping requirements
Date: Wed, 27 Jan 2021 21:56:24 +0100

On Wed, Jan 27, 2021 at 8:12 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> with 2.23.0 out, I'd like to update the CI image. The current one is
> based on Ubuntu 16.04 which will be EOL in April, a bit more than 2
> months from now. I think there are two logical replacements:
>  * Ubuntu 18.04, maintained until 2023-04
>  * Debian 9 Stretch, maintained until 2022-06
>
> Neither of them has Guile 1.8 packaged, so that'll have to be compiled
> when building the image anyway, but I'd like to go with Ubuntu 18.04
> because it has Guile 2.2. In contrast, Debian 9 Stretch only comes with
> guile-2.0 and I was surprised to find that LilyPond master doesn't even
> compile with 2.0 at the moment [1].
> However, there's another consideration: Ubuntu 18.04 comes with Python
> 3.6 and support for Python 3.5 (the current minimum & in Ubuntu 16.04)
> is likely to break without proper testing. For that reason, I think we
> should bump the requirement accordingly. The downside is that doing so
> would effectively drop support for Debian 9 Stretch with Python 3.5. I
> think that's ok given that Debian 10 Buster is the current version, but
> wanted to check if that's a problem for anybody?
> [If we agree on Ubuntu 18.04 as a kind of "minimum distribution", it
> might make sense to bump some other requirements (such as Pango to get
> rid of some compatibility code), but this can be done in due time.]

What is the downside of sticking with current 16.04? Unless we make a
conscious decision to drop support for GUILE 1.8, there is not much
upside to moving to the newer versions.  Dropping support for 1.8 has
the potential to simplify a lot of GC related code, but IIRC, it's
still a bit slower.

> Cheers
> Jonas
>
>
> 1: Overlay_string_port relies on scm_c_make_port_with_encoding which
> doesn't exist in Guile 2.0. I haven't looked if there's a replacement,
> but I find it unlikely and think the time would be better spent on a
> working version with Guile 2.2.



-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen



reply via email to

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