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.
