Am Samstag, dem 19.02.2022 um 21:34 +0100 schrieb Jean Abou Samra: > Le 19/02/2022 à 21:00, Jonas Hahnfeld a écrit : > > I'm firmly convinced that the order must be > > 1. only test with Guile 2.2 in CI > > 2. make configure only look for Guile 2.2 by default > > 3. do a release with Guile 2.2 only > > 4. unless emergency happens, drop all code related to Guile 1.8 very > > soon after > > I disagree with 'very soon after' in point 4. Is this code > really hurting? We don't have so much of it as far as I can > see.
All "guile-2" in scm/, GUILEV2 in lily/, and a number of configure checks. It will be significantly easier to restructure all of our Scheme code without that. Plus, your plan of keeping code for Guile 1.8 doesn't work / make sense without keeping GUB working. That is far more complicated and prevents many future changes. > I find it too risky to lock ourselves into Guile 2 in > a state where a stable release would not be satisfactory > (see also below). Plus, a number of problems have been popping up > with the new binaries. It's great that you're fixing them > at the speed of light (thanks!), but I'm not convinced by > waiting only shortly after a new release to call it good > to go. Would it consume excessive CI minutes if we tested > with both Guile 1 and 2 for some time? If so, I would > suggest having optional jobs with Guile 1, basically swapping > the current roles. Again, this doesn't make sense: If we want to keep Guile 1.8 working, the jobs must be mandatory. So we're talking at least twice the CI minutes, in practice much more because frog can only run one job at a time.
signature.asc
Description: This is a digitally signed message part
