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.

Walter Bright, el 14 de octubre a las 20:46 me escribiste:
> 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.

Thanks for the first releases with full svn history! 8-)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Wake from your sleep,
the drying of your tears,
Today we escape, we escape.

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.

Sweet, JSON output, looks like it wasn't very hard to write :)

Jeremie Pelletier wrote:
> Sweet, JSON output, looks like it wasn't very hard to write :)

It was rather trivial. But it's a bit primitive right now. The problem is I'm not writing a consumer of this data, so I'm not sure what it should contain. Consider it as a trial balloon.

I'm interested in hearing from those who are making plugins to Vim, Emacs, source code browsers, etc., who can use this, and what more is needed.

I don't want to just throw in a grab-bag of cruft.

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.

Thanks for the new release!  I have built QtD r304 (latest) with DMD 2.050, and a tutorial example worked successfully.

Bugzilla admin, could you add 1.050 and 2.035 to the versions dropdown list?

Walter Bright:

Using DMD 2.035 I have tried to compile:

void main() {}

Using:

dmd -X temp.d

And the compiler crashes.

Regarding the "-X" name, isn't something like "-json" better? Or better to unify the switch for json output and normal ddoc output in some way.
Even better, DMD2 compilation switches may need a bit of global clean-up/rationalization (and they must be chosen taking in account the needs and constraints of the LDC compiler too, so both compilers can share all or most the same switches, simplifying the change of compiler a bit).

Bye,
bearophile

bearophile wrote:
> Walter Bright:
> 
> Using DMD 2.035 I have tried to compile:
> 
> void main() {}
> 
> Using:
> 
> dmd -X temp.d
> 
> And the compiler crashes.

Sorry, that happens if the source file doesn't have a module statement.

MIURA Masahiro wrote:
> I have built QtD r304 (latest) with DMD
> 2.050,

Of course that's 2.035.  I'm screwed by rapid releases :-)
(I do welcome rapid releases, though)

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.

== Quote from digited (digited@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.