Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

[Jonas Hahnfeld]

Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > 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