Release planning for 2.063
Johannes Pfau
nospam at example.com
Mon Feb 25 10:47:19 PST 2013
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
If we decide to do minor releases after that release the dates could
look like this:
2.063.1
RC 1 5 apr 2013
RC 2 10 apr 2013
Final release 15 apr 2013 (2 weeks after 2.063.0)
2.063.2
RC 1 19 apr 2013
RC 2 24 apr 2013
Final release 29 apr 2013 (2 weeks after 2.063.1)
(and 2 weeks before 2.064.0)
A long term release plan could then look like this:
http://wiki.dlang.org/User:Jpf/Release_Schedule
Let's also try to switch to the new release process completely. As the
staging branch was criticized a lot and had only minor benefits I
updated the wiki page to remove the concept of the staging branch.
Most things stay the same, some get simpler. (If it's considered rude
to just edit the wiki page or if we want to keep staging branch I'm
sorry, just revert my changes)
http://wiki.dlang.org/Development_and_Release_Process
This would mean the next step is to create the 2.063 branch next
Monday:
http://wiki.dlang.org/Development_and_Release_Process#Preparing_a_new_major_release
More information about the Digitalmars-d
mailing list