May 31, 2013
On Friday, 31 May 2013 at 00:28:58 UTC, Jesse Phillips wrote:
> Perfect chance to try out the new release process. Patch 2.063 and release 2.063.1.

Actually v2.063.1 is the current one, check the dmd tags ;)
It will be v2.063.2

P.S. It has made life of linux packagers SOOO much easier ^_^
May 31, 2013
On 2013-05-30 17:16, Andrei Alexandrescu wrote:
> Hello,
>
>
> We are pleased to announce that dmd 2.063, the reference compiler of the
> D programming language, is now available for download for OSX, Windows,
> and a variety of Unixen:
>
> http://dlang.org/download.html

The -transition=field flag seems to be undocumented.

-- 
/Jacob Carlborg
May 31, 2013
I want to express my sincere gratitude to everyone who has been involved in doing this release. It is a major breakthrough in D development and release process and a solid step towards truly mature project.

Really, a lot of small but important changes have just happened that make this release extra awesome:

1) It was a great pleasure to see real project authors coming to beta list and calling problems found by their code out loud before release is made. It is how it was intended to work and it finally works.

2) Judging by tags in D repos, new release versioning scheme is making its way into being adopted and used. That means that those few regression not caught by beta can be fixed now and release as 2.063.2, no need to wait for 2.064 and suffer. Awesome.

3) Final decision about major breaking bug fix is surprisingly wise and close to well-define transition process I have been asking for so long. (If you have missed it, it looks like this: "release n: warning, release n+1: deprecation, release n+2: new behavior") Resolution if this problem alone is a major step towards proud title of stable and mature project and I hope it won't be a rare exception ;)

4) Changelog. It rocks. It fulfills my deeply hidden desires. Andrej, you have done an astonishing job here.

Yay!
May 31, 2013
Nick Sabalausky, el 30 de May a las 22:47 me escribiste:
> On Fri, 31 May 2013 03:50:51 +0200
> "Rob T" <alanb@ucora.com> wrote:
> > Yes, but because there's no link on the main page and no installer, the RC's are effectively closed to the public because only people in the know will go through the trouble to get the RC's and install them.
> > 
> > I'm only talking about when the next release gets very to release should something like this be done. It'll make installing a new release far less risky business when it goes final. It'll improve confidence in the final product and further reduce or completely eliminate nasty surprises.
> > 
> > IMO doing this will have a similar positive effect like as we've seen with the improved release log.
> > 
> > --rt
> 
> Yea, greater visibility for the betas could probably still help.

Yeah, and that's exactly what I suggested here several times, and ultimately at DConf :). A step forward has been made in this release, as you said, betas were announced in this NG for the first time, before they were announced only in the beta ML.

Now we need to put version numbers to different betas, put a link to
them in the main page (with the complete changelog, so people also know
what's new and try the new stuff) and wait a little longer before
releasing the final version. Also, to avoid a lot of release burden,
I don't think there is a need to fix a regression and instantly
pseudo-release a new beta, ending with 6 or 7 betas. Is better to wait
a little longer between releases and get more fixes in each release
(unless there is a very bad regression that makes the compiler almost
unusable). Maybe having something like a fixed weekly release of betas
would be a good idea. If one week there are no more bug reports against
the beta, then release that as the final version.

Betas are really release candidates, I think it might be a good idea to just start calling them what they are, so people is more tempted to download them and try them.

I hope next time it is DMD 2.064rc1, 2.064rc2, etc...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Fantasy is as important as wisdom
May 31, 2013
Dicebot, el 31 de May a las 10:01 me escribiste:
> On Thursday, 30 May 2013 at 22:41:08 UTC, Rob T wrote:=
> >Prior to issuing a release like this, it should instead be made public as a "stable release candidate" with full installer on the downloads page for review by anyone. After the bugs are worked out and some time has elapsed, the stable RC is simply declared "stable final" and re-released as such with the usual big announcement.
> >
> >--rt
> 
> I disagree. Anything made public is treated as a release.

This is just plain and completely wrong. I don't know many big-ish opensource projects that doesn't have release candidates, and I haven't see any "distribution" targeted at end users using release candidates.

Have you ever see a Linux distribution shipping an rc kernel (that is not only installable by explicit user action) for example?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
JUGAR COMPULSIVAMENTE ES PERJUDICIAL PARA LA SALUD.
	-- Casino de Mar del Plata
May 31, 2013
On Friday, 31 May 2013 at 00:28:58 UTC, Jesse Phillips wrote:
> On Thursday, 30 May 2013 at 22:04:07 UTC, Andrej Mitrovic wrote:
>> On 5/30/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>> Hello,
>>
>> We seem to have a regression affecting the zipped release:
>> http://d.puremagic.com/issues/show_bug.cgi?id=10215
>>
>> But I can't recreate this in git-head. It must have been a specific
>> commit the release is based on that introduced this behavior. I don't
>> know how it went through the autotester unnoticed, this is a pretty
>> major bug.
>
> Perfect chance to try out the new release process. Patch 2.063 and release 2.063.1.

That would be good. The problem is a bit annoying.
May 31, 2013
Damn you D - I'm using up a large chunk of my free time reading the improved and very-readable Change Log.

A great update to D and Log.

-=mike=- 

May 31, 2013
Great work all  :-)

Many thanks to everyone involved, it really is appreciated.

Stewart
May 31, 2013
On Friday, 31 May 2013 at 09:08:17 UTC, Leandro Lucarella wrote:
> This is just plain and completely wrong. I don't know many big-ish
> opensource projects that doesn't have release candidates, and I haven't
> see any "distribution" targeted at end users using release candidates.
>
> Have you ever see a Linux distribution shipping an rc kernel (that is
> not only installable by explicit user action) for example?

Oh, I have meant it completely other way around - if some release is made available through common channels it does not matter if it is called "beta" or "RC", people will just start using it. Remember the issue with UDA syntax?

In mature projects RC does not differ that much from actual release other than by extra regression fixes. But for D process is not THAT smooth enough and it will take some time to settle things down.
May 31, 2013
Dicebot, el 31 de May a las 10:11 me escribiste:
> I want to express my sincere gratitude to everyone who has been involved in doing this release. It is a major breakthrough in D development and release process and a solid step towards truly mature project.
> 
> Really, a lot of small but important changes have just happened that make this release extra awesome:
> 
> 1) It was a great pleasure to see real project authors coming to beta list and calling problems found by their code out loud before release is made. It is how it was intended to work and it finally works.
> 
> 2) Judging by tags in D repos, new release versioning scheme is making its way into being adopted and used. That means that those few regression not caught by beta can be fixed now and release as 2.063.2, no need to wait for 2.064 and suffer. Awesome.

About this, AFAIK 2.063.1 is really what's in the release, but the binary version number (and the zip name) have only 2.063. I think that should be fixed and the real version number should be present in both downloadables and binary. Also a micro changelog should be provided, only with the regressions that were fixed.

And I don't mean to minimize the incredible breakthrough concerning the release process in this cycle, just pointing out places were we can still do better :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Your success is measured by your ability to finish things