On Tuesday, 26 February 2013 at 04:46:12 UTC, Russel Winder wrote:
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.
+1
I would suggest that having a schedule such as this is to lead
to
problems. It is overcomplicated and over-bureaucratic. If the
intention
is to move to timeboxing of the minor releases, just allow bug
fix
releases on an as needed basis. Allowing for s.XXX.Y is a good
thing as
it means there is a route for fixing trivial things instantly
rather
than waiting for the next minor release, but no need to
schedule them.
+2
