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). 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?
signature.asc
Description: This is a digitally signed message part
