Release planning for 2.063

Dmitry Olshansky dmitry.olsh at gmail.com
Tue Feb 26 09:46:45 PST 2013


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


More information about the Digitalmars-d mailing list