Chris Miller wrote:
> On Wed, 11 Apr 2007 20:01:12 -0400, Walter Bright 
>> Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
> Here's the major one: http://d.puremagic.com/issues/show_bug.cgi?id=1130 - but not much info.

Unfortunately, there's not much I can do about it without a failing example.

> The point is that my code worked on the previous DMD version, and now it doesn't compile. Not only this bug, but my code used "ref" as a variable name and had some variables declared after "final:" that weren't meant to have the new meaning of final. This code includes -v1 in the compile script.
> 
> Should -v1 not treat "ref" as a keyword?

It was supposed to not do that, but there was a bug in that code. It's been corrected now.

> Even more painful, should -v1 not apply "final" to variables? Branching would make these easier.

I'll fix that as well for -v1.

> Any slip up on your part makes it that much harder on those who maintain and distribute code. Of course branches don't fix everything, but it's about maximizing stability and reliability and minimizing potential issues.

I understand how frustrating it can be. I'll try to get an update out today that addresses these.

Hmmm...Wouldn't it be cool if dsource.org ran overnight builds.  This would substantially increase the 'test suite'.  Of course you could never be sure if a failure was a check-in problem or a compiler problem.  But if it succeeded then you'd end up feeling much more confident about a new compiler release.

Mark


Walter Bright wrote:
> 
> The test suite is run before every new release. If things break with a new release, it is because the case isn't reflected in the test suite. Every fixed bug goes in to the test suite. For example, Kris posted two things that broke with the 1.011 update. Both are fixed now, and both are now in the test suite. They'll stay fixed.
> 
> Over time, the suite has a ratchet effect, with things getting better and better. I've been using that system for decades with the C++ compiler, and it's pretty rare for an update to break anything.
> 
> But if bugs aren't reported, then they don't get fixed, and the test case never winds up in the test suite.
> 
> The only way to get a stable system is to report bugs, fix them, and put the cases in the test suite. I tend to put priority on fixing things that break existing code; I know how maddening that can be.

On Thu, 12 Apr 2007 13:24:05 -0400, Serghei Darii <serge_ds@arcor.de> wrote:

> On Thu, 12 Apr 2007 11:43:44 +0200, Walter Bright <newshound1@digitalmars.com> wrote:
>
>> torhu wrote:
>>> I'm also having the same problems with my D projects.  I just added 'doesn't compile with 1.011' to the readme.txt for one project.
>>
>> What doesn't work with 1.011?
>
> Hi Walter,
>
> a concrete example (may be it was already reported) when I try to compile DFL lib.
> First, I have fixed for myself (not waiting for new DFL release) the .ref problem in some files.
> Second, 'final' for variables in 2-3 files.
> Third, after that, all compiled correctly in debug mode, but for relase I get:
> ...
> Internal error: ..\ztc\gflow.c 1334
> ..
>
> Yes, ... and this breaks my project.
>
> Thank you.
>
> Serghei Darii
>
>

I added to http://www.dprogramming.com/dfl.php it includes:

Tested with DMD 1.010 and 0.177
Not compatible with DMD 1.011

Please downgrade back to 1.010 at http://www.digitalmars.com/d/changelog.html#new1_010

On Thu, 12 Apr 2007 05:20:27 -0400, torhu <fake@address.dude> wrote:

> I'm also having the same problems with my D projects.  I just added 'doesn't compile with 1.011' to the readme.txt for one project.
>
> Since branches has been suggested before, and nothing has happened, I have a suggestion that might mean less extra work for Walter, but still improve the situation a bit:  Release a version marked as a beta or release candidate before the final version.
>
> If the beta version is accepted by the community (all very informal, what 'accepted' means will have to be Walter's call in each case), it can be renamed, or even just reannounced as a final version.  The zip file should at least be renamed, even if the compiler's version number is not changed (in order to avoid the risks of a recompiling and repackaging).
>

This might be a decent compromise. At least small oversights can be fixed up without affecting regular D users. Beta testers (probably those testing their libraries) can try things out and report any issues.

There could be a standard beta time, such as one week after the latest beta release, before the public version and release announcement.

Beta tests could possibly only be accessible via a new separate page and are not posted to the announce NG. Perhaps there could be a separate digitalmars.D.beta group for that instead, also for discussing beta issues.

- Chris

Chris Miller wrote:
> On Thu, 12 Apr 2007 13:24:05 -0400, Serghei Darii <serge_ds@arcor.de> wrote:
> 
>> On Thu, 12 Apr 2007 11:43:44 +0200, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> torhu wrote:
>>>> I'm also having the same problems with my D projects.  I just added 'doesn't compile with 1.011' to the readme.txt for one project.
>>>
>>> What doesn't work with 1.011?
>>
>> Hi Walter,
>>
>> a concrete example (may be it was already reported) when I try to compile DFL lib.
>> First, I have fixed for myself (not waiting for new DFL release) the .ref problem in some files.
>> Second, 'final' for variables in 2-3 files.
>> Third, after that, all compiled correctly in debug mode, but for relase I get:
>> ...
>> Internal error: ..\ztc\gflow.c 1334
>> ..
>>
>> Yes, ... and this breaks my project.
>>
>> Thank you.
>>
>> Serghei Darii
>>
>>
> 
> I added to http://www.dprogramming.com/dfl.php it includes:
> 
> Tested with DMD 1.010 and 0.177
> Not compatible with DMD 1.011
> 
> Please downgrade back to 1.010 at http://www.digitalmars.com/d/changelog.html#new1_010

Yes I know and I did, thank you.
I mentioned that because Walter was asking for an example ... had no time to write a bug.

Serghei

Chris Miller wrote:
> On Thu, 12 Apr 2007 05:20:27 -0400, torhu <fake@address.dude> wrote:
> 
>> I'm also having the same problems with my D projects.  I just added 'doesn't compile with 1.011' to the readme.txt for one project.
>>
>> Since branches has been suggested before, and nothing has happened, I have a suggestion that might mean less extra work for Walter, but still improve the situation a bit:  Release a version marked as a beta or release candidate before the final version.
>>
>> If the beta version is accepted by the community (all very informal, what 'accepted' means will have to be Walter's call in each case), it can be renamed, or even just reannounced as a final version.  The zip file should at least be renamed, even if the compiler's version number is not changed (in order to avoid the risks of a recompiling and repackaging).
>>
> 
> This might be a decent compromise. At least small oversights can be fixed up without affecting regular D users. Beta testers (probably those testing their libraries) can try things out and report any issues.
> 
> There could be a standard beta time, such as one week after the latest beta release, before the public version and release announcement.
> 
> Beta tests could possibly only be accessible via a new separate page and are not posted to the announce NG. Perhaps there could be a separate digitalmars.D.beta group for that instead, also for discussing beta issues.
> 
> - Chris

Why not simply add a line to the download page which states 'last stable version' and points to the previous download. So that newcomers to D don't download a half-hour old compiler and find that popular libraries won't compile. (a PR disaster).

BTW, to be fair, g++ 4.0 was a mess, with more codegen bugs than I've seen in any DMD release -- and that's a much higher profile project, with a much bigger team than DMD does.

I also second this.

Walter, please don't to address (just) the concrete bugs arose with the last release, but the root of the problem.

And it is definitely the development model. D is a moving target. We all love this language, but we need a stable branch with fast and frequent bugfixes.

Please listen to your users.

Reagrds,
David

David Ferenczi wrote:
> I also second this.
> 
> Walter, please don't to address (just) the concrete bugs arose with the last
> release, but the root of the problem.
> 
> And it is definitely the development model. D is a moving target. We all
> love this language, but we need a stable branch with fast and frequent
> bugfixes.
> 
> Please listen to your users.

The problem is that one cannot just do bugfixes without running the risk of breaking things. The final thing was an effort to fix the existing buggy final behavior.

0ffh wrote:
> Clay Smith wrote:
>> its stability. We could report bugs, but why report bugs when this fundamental issue can be solved by a simple change of compiler development? Some of us have little time on our hands to develop in D, 
> 
> I can't see how any bug is ever going to be fixed, if nobody reports it...

The bug will never crop up in the first place.

janderson wrote:
> Why not simply release 2 executables?  One with -v1 permanently on.  No one will be the wiser. LOL.
> 
> -Joel

It will still have the ref problem.