Re: State of LilyPond with Guile 2.2

[Jonas Hahnfeld]

Am Sonntag, dem 11.04.2021 um 22:19 +0200 schrieb Werner LEMBERG:
> > > It is very unfortunate that more recent Guile versions cause such
> > > a serious deterioration for LilyPond.  Maybe it makes sense for
> > > the foreseeable future to stay with the status quo, this is,
> > > using Guile 1.8 as much as possible,
> > 
> > For reference: Ubuntu 16.04, the longest supported version to have
> > a package for Guile 1.8, will go EOL on April 30; Debian Jessie
> > already is dead since June 2020.
> 
> Well, Guile 1.8.x served us surprisingly well in the last years.  It
> still has a maintainer, and I'm not aware of serious bugs that are
> showstoppers for LilyPond.
> 
> > > and offering support for 2.x (or 3.x) for platforms where version
> > > 1.8 can't be used.
> > 
> > The problem I see is that whatever is part of the official binaries
> > will get the most attention, or we risk giving users a
> > configuration that developers don't test regularly.  Which means
> > the other version simply won't matter and carry on their own bugs.
> 
> But we already have this situation: Almost all developers use a
> Unix-like OS and can be thus served with Guile 1.8.x!  Are there
> actually LilyPond developers who work natively with Windows or MacOS?
> With 'natively' I mean using a binary specifically compiled for that
> platform and not a virtual box.

Adding a mix of Guile versions will make the situation much worse
because we know for sure that 1.8 and 2.2 are sufficiently different
that it can cause bugs on their own. Claiming support for both will
make reproducing issues much harder, and things will get outright
horrible if, say, we continue to offer 32 bit for Windows using Guile
1.8 and 64 bit with Guile 2.2.

Also consider what this means for extension writers: They'll have to
take two Guile versions into account and possibly test both of them. I
fear this split will be equally bad as Python 2 vs 3 was over years...

Jonas

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