Release planning for 2.063

[Johannes Pfau]

Am Mon, 25 Feb 2013 19:23:35 -0500
schrieb Nick Sabalausky <SeeWebsiteToContactMe at semitwist.com>:

> On Mon, 25 Feb 2013 19:47:19 +0100
> Johannes Pfau <nospam at example.com> wrote:
> 
> > As there were complaints about not having a release schedule for
> > 2.062 and releases being made suddenly without no prior announcement
> 
> But even things are, there certainly isn't "no prior announcement".

Yeah I didn't describe that very well. There usually is a "Shall we
start a new beta" thread, then a new beta is started or sometimes not.
But you only know at max 1 week before the feature freeze when it will
happen and it also tells you nothing about the final release date. That
is kind of "suddenly".

Do you know _right now_ when 2.063 will be released or when there is a
feature freeze? In 7 weeks as the timespan between 2.061 and 2.062? In 5
months (2.060/2.061) or 3 months (2.059/2.060) or when shared libraries
are ready(feature based)?

> 
> 
> > I propose to do the feature freeze next Monday (no more new features
> > after that). At the same time the first beta is released. Then 2
> > weeks later first release candidate, one week later the next release
> > candidate and one more week to the final release:
> > 
> > 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 
> > 
> 
> Scheduling RCs and finals is a bad idea, and so is locking the number
> of RCs. RCs and finals need to come *as* problems found with the beta
> and subsequent RCs are fixed. If that ends up taking more or less
> time than some completely arbitrary predetermined "fits all sizes"
> length of time, then so be it. What you're proposing is just
> scheduling for sake of scheduling. It's just arbitrary red tape, it
> doesn't help anything.
> 

Granted scheduling RCs might be a bad idea. Having a _rough_ schedule
for the release date (e.g. feature freeze + ~4weeks) can still be useful
though to avoid blocking a release for months. Of course if new
regressions are found another RC and postponing a release for 2 weeks
wouldn't be bad.