Am Tue, 26 Feb 2013 04:45:56 +0000 schrieb Russel Winder <[email protected]>:
> 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.
