Re: Freezing for 2.18

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Mon, Mar 11, 2013 at 3:37 PM, David Kastrup <address@hidden> wrote:
>>
>>> 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.
>
> Ah, you mean that the disagreement is /only/ about whether we should
> flip the switch (make a branch) now or later?
> If so, i'd say we can do this now.  Let's see what Mike will say.

Uh Janek?  We have _never_ made a branch for stable releases until after
we reached a state of convergence.  The problem is that in order to get
a stable release from a wobbly starting base, we need testers.  If all
developers move on to the unstable branch and the unstable branch gets
extensive work, testing of the fixes required to get a release ready
will fall apart.

After cutting the stable release branch, what goes in there are
documentation fixes, well-exposed cherrypicks of bug fixes, and reverts
of regressions.  Basically stuff that is _certain_ to improve release
quality, judging from the beating it has seen in master because, like it
or not, that's what people are working with and looking at.  If the
unstable branch gets _extensive_ changes, this approach falls down.
Cherry-picking stops working, documentation changes in unstable and
stable are not exchangeable, and so on.

Last time around, we released 2.17.0 in the _wake_ of releasing 2.16.0,
and only _then_ the extensive skyline patches were placed into 2.17 and
2.17.1 was released with them.  That worked reasonably well.  We don't
have the resources for parallel development and testing, and it does not
even appear that we have the release mechanisms.

-- 
David Kastrup