zsxxsz zhengshu...@hexun.com wrote:
== Quote from digited (digi...@yandex.ru)'s article
Walter Bright Wrote:
The main purpose of this is to correct a couple of regressions that were
blocking QtD and Tango.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.050.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.035.zip
Many thanks to the numerous people who contributed to this update.
Thank you for this release, and thank you for small commits to SVN!
The only thing that is missing from a good release procedure is
_release_candidates_. Please, Walter, do not hurry with releases! With DMD in
SVN,
it will be totally ok to do releases by one in 1-2 months, the main problem is
that the developers don't have any time to actually test the new release. The
bugs
are found, but it's too late and they need to wait for new release, with new
_features_ and thus, with _sudded_ release, new bugs and breaking changes
(even in
D1, yes).
You can totally eliminate this kind of problems with posting not a Here's a
new
complete release! Now you can test it, but you won't get any fixes until next
one, but a _release_candidate_, make an SVN branch for it and let developers
(of
QtD, Tango and lots of other projects) to test the candidate and report bugs
to
you. Be sure, after a week of testing, while you can work on next release and
new
features in trunk, the release branch will really become ready for a _stable_
release, when noone will have to complain about blocker bugs.
Please, Walter, do not hurry with releases, make release candidates and wait
for
bug reports, apply fixes to the release branch and then make a really good
release, no matter not so often!
Thank you.
I don't think so. If there are some important bugs fixed, the new release is
necessary without caring about the release date. With dmd.2.034, I don't event
compile druntime.
This wouldn't have happened if there was release candidates.
