February 26, 2013
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
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
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
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
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
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
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
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
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
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.