Re: Freezing for 2.18

[David Kastrup]

Colin Hall <address@hidden> writes:

> Janek Warchoł writes:
>
>> On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup <address@hidden> wrote:
>>> So I see us at a crossroads here: either we decide we want to have a
>>> stable release in a reasonable point of time in the near future, or we
>>> decide we don't want to plan for a stable release anytime soon.
>>>
>>> If we decide we want a stable release at some point in the foreseeable
>>> future, it means to stop adding destabilizing work to master and focus
>>> on stabilizing work instead.
>>
>> Agreed.  Nevertheless, stabilizing master doesn't have to mean pausing
>> "unstable" work.  I think it can be done in a branch.
>
> Absolutely. I thought that we had adopted this proposal:
>
> http://lilypond.org/~graham/gop/gop_3.html

So what?

I quote:

    The policy is: David Kastrup has sole authority over what goes into
    stable/2.16 and which release(s) will have a version number of
    2.16.x, until 2012 Dec 31.

For one thing, we are not talking about 2.16.  For another, the deadline
has passed.

> If so, it should be clear which of the recent 2.17.x are stable.

None, by definition.  Development releases are cut regularly with
disregard to the documentation being in synch with ongoing work, or
ongoing work having reached its ultimate goal or us being reasonably
sure that a given developer release did not introduce showstopper bugs.
There is nothing wrong with that, but we still have to change gears
whenever we want to get a stable release out.

> Just cut a release based on that code.

What code?

> Add some doc updates and translations if they are available, or make
> them known issues if not. As Janek says, anything else goes into a
> branch.

That's exactly what the disagreement is about.  This "anything else goes
into a branch" is not a requirement as long as we are not shaping up for
an eventual stable release.

We are currently at a point where not flipping the switch will have a
large impact on the time we'll take to get release-ready.  Yes, it's not
exactly timely that I have come to and voiced this realization.  And
that's entirely my fault.

But that does not save us from making a decision about what to do with
that realization, since the decision (or an absence of decision) will
have an impact.

-- 
David Kastrup