Re: Stable release.

[David Kastrup]

Keith OHara <address@hidden> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>> It is a reasonably safe bet that we won't have a stable release 2.16 in
>> the next two months given our current release policies and policy change
>> policies and their past effects on release candidates.  
>
> I'll take the other side of that bet.
>
> LilyPond seems in a more stable condition than at the 2.14 release.  I
> think it is time for 2.16.

The release policies demand 2 weeks without critical regression after a
development release.  So far, we have rarely lasted a single week.  The
policies are slated for rediscussion at the end of summer.  By that
time, we'll not be hitting the freezes for the fall releases of the
distributions.

I think it is time for 2.16 as well, but it just is unrealistic to bet
on that happening before the big freezes.  We have policies, and we have
plans for reconsidering those policies, and the consequences are pretty
clear.

> The release blocking issues could be fixed with minor reverts.

The usual release blockers are not revertible.  Even if the current set
is get cleared out, history tells us that the time window of two weeks
after unstable release is unlikely to finish before the next detected
regression.

Yes, the current set can be cleared out in a few days of work, but
betting the life of LilyPond on no critical regression getting
discovered in the next cycle seems imprudent.  And make no mistake,
without _any_ usable stable release for current GNU/Linux distributions,
the life of LilyPond _is_ on the line.

>> As a sort of emergency measure, I would consider it sensible if we
>> did a source-only release of 2.14.3 or, if you want to, 2.14.2a, the
>> same as 2.14.2 plus cherry-picked compilation fixes.  Namely just
>> what it takes to get 2.14.2 through the current compilers.
>
> Very sensible.  Distributions from source should have the option to
> include a recent (especially the most recent) stable release without
> compiler gymnastics.

I think that would be no more than about 4 commits.  If nobody has a
better proposal, I'll try seeing which commits it will take to get
current 2.14 through a current Ubuntu system.  Adding the fixes for GCC
4.6 and 4.7 should do most of the trick.

-- 
David Kastrup