dmd 1.045 / 2.030 release

[Jesse Phillips]

On Tue, 12 May 2009 23:58:32 -0300, Leandro Lucarella wrote:

> Christopher Wright, el 12 de mayo a las 19:14 me escribiste:
>> Leandro Lucarella wrote:
>> >Walter Bright, el 12 de mayo a las 09:40 me escribiste:
>> >>Tomas Lindquist Olsen wrote:
>> >>>Is there a reason for the missing announcement ?
>> >>Yes, I sent it to people who'd asked for a prerelease so they could
>> >>check their builds against it.
>> >I think a better way to do prereleases is to do a "full" release but
>> >mark it as a release candidate.
>> >For example, make a DMD 1.045rc release. Wait a week, if nobody
>> >complains, release DMD 1.045. If somebody complains, fix the bug, make
>> >a DMD 1.045rc2, etc (normally the final would be the same as the rc,
>> >and there should be very rare cases where a rc2+ would be needed).
>> >Maybe it's a little more work, but I'm sure the prerelease will get a
>> >lot more testing than a hidden release and people won't get confused
>> >thinking that something that is in the website ready for download and
>> >looks like a final release, really is a "hidden prerelease". Anyways,
>> >I think pre-releasing is great and it's better to have it this way
>> >than not having them at all.
>> 
>> -rc is good when you have long release cycles. It isn't appropriate for
>> dmd, which has very short release cycles.
> 
> The Linux kernel has a release every 3 months (aprox.) and they release
> about 10 rc for each version.
> 
> DMD is released roughly every month. I think having 1 or 2 rc version
> (just when they are needed, not like the Linux kernel where it's know
> that there will be more than 5 rc for sure) makes perfect sense.
> 
>> If dmd had public source control, we could set up continuous
>> integration for it that will, for instance, run dstress and attempt to
>> compile the latest release of various common libraries. Then Walter can
>> just check its results when he wants to do a release -- depending on
>> how long that takes to run.
> 
> This would be very nice indeed, I suggested to put DMD (specially the
> frontend) in a SCM a long time ago, but I think this is orthogonal with
> the rc. A lot of people don't want to keep checking a development
> version. They just want to test the compiler as it would be release
> (considered a "finished version") to report weird regressions.

The issue with having rc releases is exactly the same as the one for the 
stable release which we already have. We don't have the people to 
coordinate when the release is "good enough." I'm not talking users, but 
those that are living on the edge and finding flaws.

Maybe what should be done is once Walter releases a version, the library 
writers that want their code working for the "stable" release should 
speak approval for increasing the stable version?