Pavel Roskin <pro...@gnu.org> writes: > Quoting David Kastrup <d...@gnu.org>: > >> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
