Jonas Hahnfeld via Discussions on LilyPond development <[email protected]> writes:
> Am Mittwoch, dem 23.02.2022 um 12:09 +0100 schrieb Han-Wen Nienhuys: >> * I grepped our source code for "guile-2" (scm) and GUILEV2, but the >> divergence of code paths seems pretty minor. Sure, it's inconvenient >> to have the odd conditional or limit ourselves to what is both in 1.8 >> and 2.2, but I'd rather see us drop 1.8 support once we see an >> obstacle that we cannot paper over. > > The problem is, in order to "see an obstacle", we always have to > invest to test every single change with Guile 1.8 and 2.2 during > development, which will be a significant time sink. If it is an obstacle, it will make itself seen soon enough. >> * The concern over CI minutes seems like it's the least important: we >> can buy more computing power (I'm happy to sponsor), and is the >> duration of CI much of a concern today? > > In the past, you've complained the loudest about slow CI builds for > merging changes... Let's focus on "today". >> If we need to kill 1.8 support because it blocks something important, >> then so be it, but given the impact on lilypond development, I'd try >> to postpone it if possible. > > So, you propose that development continues on Guile 1.8, but we > advertise that we consider Guile 2.2 ready for production use? We advertise that Guile 2.2 is considered to be workable. > I don't think that makes for a great user experience if we let them > find problems... Uh, that's the whole point of having unstable releases, isn't it? > Also "postpone" up to what point? See above regarding "obstacles". >> I'm glad to hear that, but do we know about the GUILE team's plans in >> this space? It would suck if they want to move to CPU dependent >> bytecode. > > My understanding of Guile's development is that certain developers > have ideas in their mind, and they eventually end up fully implemented > in the repository. There is no such thing as (public) plans. And that's the polite version of putting it. -- David Kastrup
