Am Samstag, den 07.03.2020, 16:24 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > [email protected] > > writes: > > > Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > [email protected] > > > > > > > writes: > > > > Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup: > > > > > We are not talking about "keep everything compatible". We are talking > > > > > about making changes in a manner where they don't trip people up. > > > > > They > > > > > way to deprecate a way of doing things is not to _start_ by pretending > > > > > it never existed and silently ignore attempts to use it. At the same > > > > > time, by the way, not adapting any bit of documentation. > > > > > > > > Acknowledged. > > > > > > > > > For better or worse, deprecation takes work. That's why we have, for > > > > > example, convert-ly. That's a user-level feature, but basically > > > > > asserting that people able to compile LilyPond have to be able to deal > > > > > with anything we throw at them without comment is not going to go down > > > > > well with regard of keeping LilyPond supported by, say, major > > > > > GNU/Linux > > > > > distributions. > > > > > > > > Do expect "major GNU/Linux distributions" to package unstable > > > > releases? I hope we don't force them by taking another 6 years for > > > > 2.22 > > > > > > You make a good argument for keeping the deprecation warnings and code > > > in for at least 2.22 so that major GNU/Linux distributions will be able > > > to follow along. > > > > > > The usual deprecation path for stuff like this is: > > > > > > 1 stable release with continued support but warning containing all > > > necessary migration information -> 2.22 > > > > > > 1 stable release with discontinued support but error containing all > > > necessary migration information -> 2.24 > > > > > > 1 stable release with active support removed but transition explained in > > > documentation -> 2.26 > > > > > > no mention anymore in code base -> 2.28 > > > > Are you serious about this for _any_ build system improvement that > > changes a little how you compile LilyPond? I'm not talking about user- > > facing stuff like notation syntax here, I would probably agree in that > > context (via convert-ly). > > Guile is not just "any" part of the build system. And we are talking > about investing an hour of work for us and milliseconds for the build > system that saves system integrators 3 hours _each_ of work figuring out > what went wrong.
My hope is that the integrators will switch to Guile 2.x anyhow once we reach a stable release. That's surely more work and likely a good time to cut old configuration variables. > At some point of time you have to ask yourself why the > time (let alone the goodwill) of downstream integrators is such garbage > that wasting it for no significant gain is a good proposition. > > > If your answer is yes, does this mean any change we do for 2.22 must > > fully preserve build system compatibility? ie the all command lines > > that work for 2.20 _must_ work for any 2.21.x and 2.22? > > Please don't play the strawman game. Not every problem is created > equal, not every solution is the same. > > Changing crucially important things in undocumented ways with silent > failure to do the expected thing is not going to make us friends. It > would be a tough task to get people to consider me friendly. But making > LilyPond friendly is a different thing. > > I don't see the point in "figure it out or die" changes. It's just not > a winning proposition. Okay, so this doesn't lead to much progress from this point. Would you be able to propose how the compatibility code for the GUILE_CONFIG variable could look like? As far as I can see that's maybe the only thing blocking a release (?). Jonas
signature.asc
Description: This is a digitally signed message part
