lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stable release.


From: David Kastrup
Subject: Re: Stable release.
Date: Tue, 26 Jun 2012 07:33:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Pavel Roskin <address@hidden> writes:

> Quoting David Kastrup <address@hidden>:
>
>> For a source-only release, we are strictly restricted to problems
>> occuring only with newer compiler versions.  Other fixes would require a
>> full rerelease including binaries.
>
> OK, that makes sense.
>
> It might be confusing for users to choose between an older binary and
> a newer source.  So it's important to make it clear on the download
> page.

Yes.  I am not saying that a full rerelease with more fixes would not
also make sense.  However, it would imply somebody (TM) would need to
roll a full release including the decision what GUB to use for it, and
it would mean a more complex decision process of what this next version
should actually include.

My proposal was just about a release addressing bit rot, namely just
making sure that the equivalent of the existing release 2.14.2 can be
compiled (with no regressions due to the recompilation) on current
systems that insist on not using precompiled binaries from us (which is
quite sensible for distributing GPLed software).

Anything else opens a much larger can of worms.  I am not saying that
this is not a good idea in itself, but it will require far more
decision-making and effort.

Personally, I don't think 2.14 would deserve that kind of effort, and I
would also consider it a bad message to the 2.16 developers.  But pure
bit rot damage control for current systems, for which we otherwise can
offer no working stable _source_ code release at all any more, seems
less contentious.  Except for the "source-code only release" part which,
of course, does not match policies.

I have no idea how hard it would be to actually roll matching binaries,
and rolling them would not actually offer any added value to users as
they would, when limiting the fixes to compilation only, be compiled
with compilers not having problems with the old source.

The fixes would be about two fixes for compiler bugs (for most 4.6
compilers and 4.7.0) and some C++ language issue IIRC.  It is likely
that the fall releases of GNU/Linux distributions would even get along
without the compiler bug fixes, but the C++ issue would require
addressing anyway IIRC.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]