View mode: basic / threaded / horizontal-split · Log in · Help
March 01, 2013
Re: Release planning for 2.063
Am Mon, 25 Feb 2013 19:23:35 -0500
schrieb Nick Sabalausky <>:

> On Mon, 25 Feb 2013 19:47:19 +0100
> Johannes Pfau <> 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.
March 01, 2013
Re: Release planning for 2.063
Am Tue, 26 Feb 2013 12:41:27 -0500
schrieb Andrei Alexandrescu <>:

> On 2/26/13 10:34 AM, Dicebot wrote:
> > On Tuesday, 26 February 2013 at 15:29:55 UTC, Steven Schveighoffer
> > wrote:
> >> That is more of a factor of the moratorium on changes while the
> >> release is being tested.
> >>
> >> I think if we branch the new development while a release is in
> >> progress, we shouldn't have this problem.
> >>
> >> -Steve
> >
> > According to approved release process in wiki we already are
> > supposed to do it. (Only other way around, branching new release
> > without freezing master).
> It has happened for the past 2-3 cycles already.
> Andrei

That's not the same thing though.

The important part is the time span _between_ feature freeze and
release. This is the time where the release is being prepared,
regressions get fixed and no new features are accepted. More time
between feature freeze and release should therefore lead to better
tested releases and less stress for developers.

According to the wiki process that time span would have been date of
new release - date of old release = 7 weeks.

The last pull request pushed to master included in the beta was

that was only 11 days before the actual release date so our feature
freeze period was only 11 days.
March 01, 2013
Re: Release planning for 2.063
01-Mar-2013 18:18, Johannes Pfau пишет:
> Am Tue, 26 Feb 2013 21:46:45 +0400
> schrieb Dmitry Olshansky <>:
>> 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.
> Maybe this is useful if used additionally, but it can't replace betas
> or minor releases.

Yes, see below. Betas are nightlies published from frozen branches like 

>> 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!
> Sure, this should be done anyway.
>> 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.
> We currently don't use release/version branches as it was described on
> the old wiki page though. At some point we'd have to start using those
> anyway and the staging branch is not really necessary anymore as the
> release branches can take the role of master. So I hoped those changes
> to the wiki page would make it easier to switch to the new process.

I posted these not to discourage the whole "wiki thing" but to 
illustrate a point that perhaps aiming for one step at a time changes 
(tweaks) is better. Then we can improve release process significantly 
without adding extra complication.

Dmitry Olshansky
March 01, 2013
Re: Release planning for 2.063
Am Tue, 26 Feb 2013 11:02:44 -0800
schrieb Brad Roberts <>:

> On 2/25/2013 11:41 PM, Jesse Phillips wrote:
> > Onto the bad news. The automated test suite isn't really prepared
> > for these changes, and I would consider it too valuable to move
> > into a branching model where the release candidate isn't getting
> > run. I did request the new processing be used on the beta
> > announcement, but having remembered this I've changed slightly on
> > pushing this.
> You're somewhat out of touch / date.  The auto testing system has
> been multi-branch aware for the last 2 releases.

Does it automatically pick up new branches or does it require manual
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home