Am Samstag, den 14.03.2020, 11:36 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > [email protected] > > writes: > > > Am Samstag, den 14.03.2020, 11:17 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > [email protected] > > > > > > > writes: > > > > Am Samstag, den 14.03.2020, 10:50 +0100 schrieb David Kastrup: > > > > > Jonas Hahnfeld < > > > > > [email protected] > > > > > > > > > > > > > > > > writes: > > > > > > Am Freitag, den 13.03.2020, 23:09 -0600 schrieb Anthony Fok: > > > > > > > On Fri, Mar 13, 2020 at 2:02 AM Jonas Hahnfeld < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > I'm still not convinced that we need compatibility code, but > > > > > > > > I'm happy > > > > > > > > with anything that gets us to a release and is not technically > > > > > > > > wrong. > > > > > > > > > > > > > > By the way, from a Debian package maintainer point of view, > > > > > > > breaking > > > > > > > backward compatibility is OK as long as it is documented, so if > > > > > > > breaking backward compatibility makes the code cleaner, more > > > > > > > correct, > > > > > > > and/or easier to maintain for the future, I'd say "please break > > > > > > > compatibility"! > > > > > > > > > > > > I definitely think that's the case here. > > > > > > > > > > Backward compatibility will always get retired eventually. For the > > > > > current decision the main target is not really distributions since > > > > > those > > > > > tend not to package unstable versions anyway. > > > > > > > > Exactly my argument in the past. So who is the "main target" in your > > > > opinion? I mostly remember the term "system integrators". > > > > > > Is there a reason we should not be catering well to either? > > > > I still don't understand who your "main target" is. Wrt "system > > integrators" Anthony wrote that breaking compatibility is fine (for > > major versions) as long as there is documentation. > > Our current state is breaking things silently and without documentation > that were required to get things working before. > > The consequences are different for different people, depending on their > contact with LilyPond and their skill sets in dealing with such > problems. This is a problem with keeping our current processes > depending on volunteers operating as expected. That also maps to people > expected to compile their own versions. Distributions like those for > Debian, FreeBSD and more recently also MacOSX work independently from > our core developer team and should be able to get results they expect. > > What is the problem you are trying to address with your "main target" > question?
I'm trying to find a way forward so we can get 2.21.0 released. I've thrown out a few ideas which you've all said we should not do. So what do you want?! This discussion is dead without knowing that. Let me rephrase what I think we should do: 1) Keep using pkg-config to find Guile. 2) Add an error if we detect that a configuration uses the old GUILE_CONFIG. 3) Add documentation about how to make pkg-config find the right version of Guile, saying that 1.8 is still the one you should target for now. Jonas
signature.asc
Description: This is a digitally signed message part
