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

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Samstag, den 14.03.2020, 11:17 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> address@hidden
>> > writes:
>> 
>> > Am Samstag, den 14.03.2020, 10:50 +0100 schrieb David Kastrup:
>> > > Jonas Hahnfeld <
>> > > address@hidden
>> > > 
>> > > > writes:
>> > > > Am Freitag, den 13.03.2020, 23:09 -0600 schrieb Anthony Fok:
>> > > > > On Fri, Mar 13, 2020 at 2:02 AM Jonas Hahnfeld <
>> > > > > address@hidden
>> > > > > 
>> > > > > 
>> > > > > > 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?

-- 
David Kastrup