zsxxsz Wrote:

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

So you don't mind that Tango is still uncompilable with 1.050 because of hurrying, for third release in a row?
There must be an easy compiling of DMD from source, and you can get your own version from SVN trunk with a fresh bugfix you need.

But a release must generally be stable and should not break the code of main D projects (or give them time to change the projects' code and fix DMD bugs), there's a point in nighly builds, but not weekly releases that keep breaking the code.

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.

The json output looks cool. :)

But for this:

---
module main;
alias int myInt;
myInt x;
---

I get:

---
{
"name" : "main",
"kind" : "module",
"file" : "main.d",
"members" : [
{
"name" : "myInt",
"kind" : "alias",
"type" : "int",
"line" : 5}
,{
"name" : "x",
"kind" : "variable",
"type" : "int",
"line" : 7}
]
}
---

So you see, variable's type is "int", not "myInt". I knew this was going to happen because the way dmd is implemented and how it fogets about aliases of types (it just resolves them and forgets about the original alias name). I had some head-aches remembering those things in Descent. :-P

Think of binding libraries like OpenGL, DirectX, even the windows API where all functions receive and return aliases. If an IDE shows the resolved aliases it's no use to the user, that's what aliases are for.

Should I create an enhancement for this?

digited wrote:
> So you don't mind that Tango is still uncompilable with 1.050 because of hurrying,

I didn't know that. The bugzilla number which was posted as the reason it wouldn't compile was fixed.

Ary Borenszweig wrote:
> Should I create an enhancement for this?

Might as well.

Walter Bright Wrote:

> digited wrote:
> > So you don't mind that Tango is still uncompilable with 1.050 because of hurrying,
> 
> I didn't know that. The bugzilla number which was posted as the reason it wouldn't compile was fixed.

I don't try to accuse you on anything, just ask to give the users some time to test a release candidate - that will show existing blockers better than posting & scanning bugzilla before sudden release, devs will fix their bugs and you'll get a feedback for fixes, and there (i hope) won't be critical problems in compiling existing projects after release.

If you are already sending rc's to Tango devs, you simply can make them public and make an SVN branch with their code.

On Wed, 14 Oct 2009 20:46:25 -0700, 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.

Hi Walter,

Thanks for the commits to svn for us to testing!
But the release came in a bit of a hurry.
I reported two more regressions, thought there weren't marked as those
because, well, I forgot to check all options.

Walter Bright wrote:
> Bugzilla 1534: Can't mix in a case statement.

Woo hoo!

Walter Bright Wrote:

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

Maybe there should be an error then?

Michael P. wrote:
> Walter Bright Wrote:
> 
>> 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.
> 
> Maybe there should be an error then?

I think he says it's a bug, he forgot a module declaration can be null. :)

zsxxsz <zhengshuxin@hexun.com> wrote:

> == 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.
> 
This wouldn't have happened if there was release candidates.