Re: Freezing for 2.18

[Trevor Daniels]

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.

Trevor