View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2013
Re: Release planning for 2.063
On 2/26/13 3:09 PM, Jacob Carlborg wrote:
> On 2013-02-26 18:41, Andrei Alexandrescu wrote:
>
>> It has happened for the past 2-3 cycles already.
>
> Then why is it always such a rush to get form beta to release?

So much to do, so little time...

Andrei
February 27, 2013
Re: Release planning for 2.063
On Tuesday, 26 February 2013 at 22:39:13 UTC, Andrei Alexandrescu 
wrote:
> On 2/26/13 3:09 PM, Jacob Carlborg wrote:
>> On 2013-02-26 18:41, Andrei Alexandrescu wrote:
>>
>>> It has happened for the past 2-3 cycles already.
>>
>> Then why is it always such a rush to get form beta to release?
>
> So much to do, so little time...
>
> Andrei

So much to break.
February 27, 2013
Re: Release planning for 2.063
On 2013-02-26 21:05, Russel Winder wrote:
> On Tue, 2013-02-26 at 13:36 -0500, Nick Sabalausky wrote:
> […]
>> *cough* DVM
>
> 1. I had forgotten about that :-(
>
> 2. Doesn't it only support DMD?

Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as DMD?

-- 
/Jacob Carlborg
February 27, 2013
Re: Release planning for 2.063
On Wednesday, 27 February 2013 at 12:50:57 UTC, Jacob Carlborg 
wrote:
> On 2013-02-26 21:05, Russel Winder wrote:
>> 2. Doesn't it only support DMD?
>
> Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as 
> DMD?

There are »DMD-style« binary packages for LDC releases.

David
February 27, 2013
Re: Release planning for 2.063
On 2013-02-27 20:34, David Nadlinger wrote:

> There are »DMD-style« binary packages for LDC releases.

Right, I noticed that. Thanks, it would be a pain in the ass to have the 
tool building LDC/GDC.

* Is there a central location for these releases?
* Can I count on it being a new pre-compiled package there for every new 
release?
* For which platform is the pre-compiled package available

-- 
/Jacob Carlborg
February 27, 2013
Re: Release planning for 2.063
On Wed, 2013-02-27 at 20:34 +0100, David Nadlinger wrote:
> On Wednesday, 27 February 2013 at 12:50:57 UTC, Jacob Carlborg 
> wrote:
> > On 2013-02-26 21:05, Russel Winder wrote:
> >> 2. Doesn't it only support DMD?
> >
> > Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as 
> > DMD?
> 
> There are »DMD-style« binary packages for LDC releases.

It would be really great if LDC and GDC had packages in D-Apt, along
with DMD, Vibe.d, etc.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
February 27, 2013
Re: Release planning for 2.063
On Feb 27, 2013 12:56 PM, "Jacob Carlborg" <doob@me.com> wrote:
>
> On 2013-02-26 21:05, Russel Winder wrote:
>>
>> On Tue, 2013-02-26 at 13:36 -0500, Nick Sabalausky wrote:
>> […]
>>>
>>> *cough* DVM
>>
>>
>> 1. I had forgotten about that :-(
>>
>> 2. Doesn't it only support DMD?
>
>
> Yes, unfortunately. Do GDC or LDC have pre-compiled binaries as DMD?
>

Not built by myself, but there are many ways you can do it.  Eg: launchpad
repository.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
February 28, 2013
Re: Release planning for 2.063
On 2013-02-27 22:17, Iain Buclaw wrote:

> Not built by myself, but there are many ways you can do it.  Eg:
> launchpad repository.

Are you referring to https://launchpad.net/gdc ?
It would be nice to have pre-compiled self contained releases for all 
supported platforms. In the same style as DMD.

-- 
/Jacob Carlborg
March 01, 2013
Re: Release planning for 2.063
Am Tue, 26 Feb 2013 04:45:56 +0000
schrieb Russel Winder <russel@winder.org.uk>:

> On Mon, 2013-02-25 at 19:47 +0100, Johannes Pfau wrote:
> […]
> > 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 
> 
> I have yet to find an organization that used this sort of scheduling
> successfully. Feature freeze fine, beta 1 fine. RC is a release
> candidate not a beta. If no-one finds a problem with a release
> candidate it is relabelled the final release. Thus scheduling an RC2
> is a failure of RC1 to be an RC at all.

Sorry for this late answer, I couldn't answer the last few days.

You're probably right, my proposal is probably overzealous. I think we
should at least schedule feature freeze but we should also try to
schedule the final release. Of course if we find unexpected regressions
the release can always be delayed, we might also release earlier if no
issues pop up in the RC.

I think scheduling the release date is important because if we do not
schedule this we can get into similar situations as with the 2.061
release which was 5 months after 2.060 according to the changelog. If
someone is just waiting for a minor fix which is already applied in git
master it is unacceptable to wait 5 months for that fix only because
there is no release date or because some other feature is not ready
yet.
March 01, 2013
Re: Release planning for 2.063
Am Tue, 26 Feb 2013 21:46:45 +0400
schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:

> 
> 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.

> 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.
1 2 3 4
Top | Discussion index | About this forum | D home