Re: Blockers for Guile 2.2

[David Kastrup]

Jonas Hahnfeld via Discussions on LilyPond development
<lilypond-devel@gnu.org> 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