25-Feb-2013 22:47, Johannes Pfau пишет:
As there were complaints about not having a release schedule for 2.062
and releases being made suddenly without no prior announcement, how
about planning the 2.063 release now?
2.062 was released ~7 weeks after 2.061. I think targeting 6 weeks
between 2.062 and 2.063 might be a good idea. The proposed days are
always Mondays. It doesn't really matter if the release is exactly on
that day but we should try to release in the week starting that Monday.
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
[snip]
The more I see topics on release process the more I feel uneasy.
Can't we just make releases more stable by doing 2 things instead:
a) Provide nightly builds - same package as beta/release but as a weekly
from Git master.
b) List links to these and betas somewhere *prominent* damn it.
*Separate* beta mailing list is *not* good enough. Post it on D,
D.announce and somewhere else as well. Let people use them!
The benefit is that both of these can be fully automated.
What is already done is staging branch to avoid freezing the master.
Betas are then just nightly builds for the staging branch and are
provided few weeks before the release. So all of this already fits the
current scenario.
--
Dmitry Olshansky
