Release planning for 2.063

[deadalnix]

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