dmd 1.045 / 2.030 release

[Christopher Wright]

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.

Releases take effort. If more people were involved with D -- even in a 
decoupled sense, which could be provided simply by putting DMD on public 
source control -- then people other than Walter could manage release 
candidates.

Don mentioned that there are, in fact, release candidates for dmd. 
However, private RCs are easier to manage than public ones.

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

Automating as much of that as possible would help.