Build Master: Scheduling II

[tn]

In general this sounds great. However:

On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
> Betas will be released four weeks after an official release.

Does this mean that a new release branch will be created at that 
point? I think it makes sense.

> Once a release candidate is published, no new features will be 
> added.

Does this imply that new features are still added in beta phase? 
That does not fit well with creating the branch in the beginning 
of the beta phase.

My opinion:

I don't think new features should be added in beta phase. Instead 
it should be for bug fixing. When no known blocker bugs are left, 
a release candidate phase should be started. Relase candidate 
should be, as the name implies, a candidate for release. Thus, if 
no new critical bugs are found, then the release can be made in 
principle just by bumping the version number.

More important than defining when the actual releases are made, 
is to define when branching is done. It is easy to slip release 
date because of new bugs and that can then delay the next release 
(depending on how you implement the procedure). Instead, a new 
release branch should be branched from the master branch exactly 
every 8 weeks. That should be easy, since there are no such 
stability requirements as for actual releases. Whether the 
following stabilisation phase (betas + release candidates) lasts 
exactly 3 or 4 or 5 weeks is not that important as long as the 
quality of the release will be acceptable. The phase should last 
long enough that all blocker bugs are fixed. In this model the 
time between actual releases can vary a bit, but on average it 
will be exactly 8 weeks.