Release planning for 2.063

[Johannes Pfau]

Am Tue, 26 Feb 2013 04:45:56 +0000
schrieb Russel Winder <russel at winder.org.uk>:

> On Mon, 2013-02-25 at 19:47 +0100, Johannes Pfau wrote:
> […]
> > Feature freeze     4 mar 2013
> > Beta 1             4 mar 2013
> > RC 1               18 mar 2013
> > RC 2               25 mar 2013
> > Final release      1 apr 2013 
> 
> I have yet to find an organization that used this sort of scheduling
> successfully. Feature freeze fine, beta 1 fine. RC is a release
> candidate not a beta. If no-one finds a problem with a release
> candidate it is relabelled the final release. Thus scheduling an RC2
> is a failure of RC1 to be an RC at all.

Sorry for this late answer, I couldn't answer the last few days.

You're probably right, my proposal is probably overzealous. I think we
should at least schedule feature freeze but we should also try to
schedule the final release. Of course if we find unexpected regressions
the release can always be delayed, we might also release earlier if no
issues pop up in the RC.

I think scheduling the release date is important because if we do not
schedule this we can get into similar situations as with the 2.061
release which was 5 months after 2.060 according to the changelog. If
someone is just waiting for a minor fix which is already applied in git
master it is unacceptable to wait 5 months for that fix only because
there is no release date or because some other feature is not ready
yet.