On 11 mars 2013, at 16:32, "Trevor Daniels" <
address@hidden> wrote:
>
> David Kastrup wrote Sunday, March 10, 2013 5:32 PM
>
>> 2.16 is growing old.
>>
>> So I want to see 2.18 soon. That means we need to stabilize work that
>> has already been done and cut down on experiments in the master branch.
>
> Agreed.
>
>> Stabilizing means more or less accepting the current feature set, and
>> making sure it works as intended, is a useful combination of things,
>> does not offer interfaces which are sure not to survive into the next
>> stable version, and most of all, is properly documented to the user.
>
> Once the decision to stabilise is taken, further work on new features
> should take place in branches. It doesn't have to stop. That's how the
> skyline code was developed before it was merged into 2.17 and that
> procedure worked well.
>
>> At any rate, I'd like to aim for 2.18 at about the end of May, and
>> getting into serious freeze at the end of April. A focus on bug fixes,
>> in particular bugs introduced in the 2.17 development cycle, should take
>> priority. Fixing long-standing bugs hard to address should likely be
>> left for early 2.19 and/or be done in a branch.
>
> Why not freeze sooner? The current state is sufficiently different from
> 2.16 to justify a new stable.
>
> I'd also like to propose we adopt the same controls as we did for 2.16,
> if David is willing, since that also worked well. That way we'll get a
> clear plan - what must be fixed, what must be documented, what is
> permitted to go into master, etc. Otherwise we'll simply disagree for
> ever.
>