Am Mon, 25 Feb 2013 19:23:35 -0500 schrieb Nick Sabalausky <[email protected]>:
> On Mon, 25 Feb 2013 19:47:19 +0100 > Johannes Pfau <[email protected]> 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.
