Walter Bright 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?

Issue 1127 (-v1 doesn't disable the ref and macro keywords), and 1135 (invariant keyword parsing is messed up).  The first one is fixed in 1.012, I reported the other one too late it seems.

Walter Bright wrote:
> Frank Benoit (keinfarbton) wrote:
>> I like this proposal.
>> And i think that ppl will test the beta. Even ppl on larger projects
>> will test it, because they *want* a stable version.
> 
> I'm not sure what it buys, since 1.011 obviously breaks things, and I'll fix it as soon as I can.


This is pasted from the readme.txt for my DWT app:

---
Versions 0.174 to 1.0 should work.
Versions 1.001 to 1.006 do not work properly with DWT apps.
Version 1.007 through 1.010 works.
Versions 1.011 and 1.012 do not work.
---

Maybe I'm taking the wrong approach to this.  But I don't know how I could realistically avoid it.  Being able to replace it with 'A beta compiler version might not be able to build this project' would be nice.

Walter Bright wrote:
> 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.

I understand what you're saying, Walter, but I don't think that what you're saying is totally fair.  As I see it, there are several different types of fixes/changes that one makes in a project:

1) Fixes to resolve things that are clearly bugs, like incorrect code generation, compiler crashes, etc.
2) Fixes to correct "misfeatures."  These are things that are currently functional, but may not be working according to the spec (such as final)
3) New features

What I think people are asking is that you branch the code so that the stable branch only gets type (1) fixes.  It might, rarely, get type (2) fixes, but only after careful consideration and warning to the community BEFORE you implement it.  The point is: the "stable" branch should not be changing anything which a user might reasonably think is "working correctly."  Even if you think it is a misfeature, or it doesn't match the spec, you generally leave it as-is, and simply post a README with the "stable" branche which lists these lingering issues.

I'm not saying that you have any particular obligation to do this, Walter...it is certainly within your perogative to say no.  But at this point in the lifetime of D, doesn't *somebody* have to do it?

torhu wrote:
> This is pasted from the readme.txt for my DWT app:
> 
> ---
> Versions 0.174 to 1.0 should work.
> Versions 1.001 to 1.006 do not work properly with DWT apps.
> Version 1.007 through 1.010 works.
> Versions 1.011 and 1.012 do not work.
> ---
> 
> Maybe I'm taking the wrong approach to this.  But I don't know how I could realistically avoid it.

I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.

Walter Bright napisał(a):
> torhu wrote:
>> This is pasted from the readme.txt for my DWT app:
>>
>> ---
>> Versions 0.174 to 1.0 should work.
>> Versions 1.001 to 1.006 do not work properly with DWT apps.
>> Version 1.007 through 1.010 works.
>> Versions 1.011 and 1.012 do not work.
>> ---
>>
>> Maybe I'm taking the wrong approach to this.  But I don't know how I could realistically avoid it.
> 
> I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.


The problem is when another library has something similar in its README.txt and misfortunately you can not find version of DMD which works with BOTH :-|

BR
Marcin Kuszczak
aarti_pl

Walter Bright wrote:
> torhu wrote:
>> This is pasted from the readme.txt for my DWT app:
>> 
>> ---
>> Versions 0.174 to 1.0 should work.
>> Versions 1.001 to 1.006 do not work properly with DWT apps.
>> Version 1.007 through 1.010 works.
>> Versions 1.011 and 1.012 do not work.
>> ---
>> 
>> Maybe I'm taking the wrong approach to this.  But I don't know how I could realistically avoid it.
> 
> I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.

The problem wouldn't go away, but it would be greatly reduced.  The serious new bugs in 1.011 were discovered almost immediately after the release.  Wouldn't it be better if 1.011 was marked as a beta, and not unleashed on the general public until the core D user community had at least verified that their apps and libs build with it?

Then you wouldn't need to rush out emergency fixes, like 1.002 through 1.004. You could wait until the dust settles, and maybe get all new bugs fixed in just a single second beta release.  1.012 might also have been a bit premature.  I just didn't have time to look into and create a test case and bug report for the invariant parsing issue (bugzilla 1135) until yesterday.  That issue seems pretty serious to me, and my app won't build until it's fixed.

Not have some kind of separation between bleeding edge and proven stable compiler versions creates a lot of confusion and headaches for everyone.


PS. I don't mean to sound like I'm not grateful for what you do, I still love working with D. Just trying to give constructive feedback. ;)

torhu wrote:
> Walter Bright wrote:
>> torhu wrote:
>>> This is pasted from the readme.txt for my DWT app:
>>>
>>> ---
>>> Versions 0.174 to 1.0 should work.
>>> Versions 1.001 to 1.006 do not work properly with DWT apps.
>>> Version 1.007 through 1.010 works.
>>> Versions 1.011 and 1.012 do not work.
>>> ---
>>>
>>> Maybe I'm taking the wrong approach to this.  But I don't know how I could realistically avoid it.
>>
>> I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.
> 
> The problem wouldn't go away, but it would be greatly reduced.  The serious new bugs in 1.011 were discovered almost immediately after the release.  Wouldn't it be better if 1.011 was marked as a beta, and not unleashed on the general public until the core D user community had at least verified that their apps and libs build with it?

How's a post in D.announce "unleashing it on the general public"??

I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a D that works for you, don't upgrade? And if you want to play with new stuff, you upgrade.

L.

Lionello Lunesu wrote:
> torhu wrote:
>> The problem wouldn't go away, but it would be greatly reduced.  The serious new bugs in 1.011 were discovered almost immediately after the release.  Wouldn't it be better if 1.011 was marked as a beta, and not unleashed on the general public until the core D user community had at least verified that their apps and libs build with it?
> 
> How's a post in D.announce "unleashing it on the general public"??

The point is that there the announcements and the version numbering is exactly the same for all versions, nothing is marked as being stable or unstable.

Look at this page and tell me which versions are stable and which are not.  The only way to judge a version's stability is by looking at the changelog of the succeeding version, and how soon after it was released.  No other clues are given.
http://www.digitalmars.com/d/changelog.html

> 
> I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a D that works for you, don't upgrade? And if you want to play with new stuff, you upgrade.

This would be fine if only a single person were to compile any given app or library.  And if all apps/libs that each user has would build with the same version.  I have currently eleven dmd versions installed, but I wouldn't want users of my libs to need to switch versions if that could be avoided in any way.  To be fair, I only use one or two versions at a time, the other are for compatibility testing, etc.

torhu wrote:
> Lionello Lunesu wrote:
>> torhu wrote:
>>> The problem wouldn't go away, but it would be greatly reduced.  The serious new bugs in 1.011 were discovered almost immediately after the release.  Wouldn't it be better if 1.011 was marked as a beta, and not unleashed on the general public until the core D user community had at least verified that their apps and libs build with it?
>>
>> How's a post in D.announce "unleashing it on the general public"??
> 
> The point is that there the announcements and the version numbering is exactly the same for all versions, nothing is marked as being stable or unstable.
> 
> Look at this page and tell me which versions are stable and which are not.  The only way to judge a version's stability is by looking at the changelog of the succeeding version, and how soon after it was released.  No other clues are given.
> http://www.digitalmars.com/d/changelog.html

But "stable" and "beta" are relative terms. For some people 1.011 solved their problems so for them 1.011 might be the only stable version.

>> I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a D that works for you, don't upgrade? And if you want to play with new stuff, you upgrade.
> 
> This would be fine if only a single person were to compile any given app or library.  And if all apps/libs that each user has would build with the same version.  I have currently eleven dmd versions installed, but I wouldn't want users of my libs to need to switch versions if that could be avoided in any way.  To be fair, I only use one or two versions at a time, the other are for compatibility testing, etc.

I think it's very normal to provide a "required compiler version" for any distributed source package. And this is nothing specific to D or DMD: even projects for Visual Studio required either 6.0 or 2002 or 2003 or 2005 or 2005 SP1. Granted, this list doesn't change on a week-to-week basis, but the idea is the same: the users of the sources must know what compiler the sources have been tested with.

Of course, as somebody mentioned, you get into a deadlock if you want to use two libraries but one library only compiles with DMD 1.007 and the other needs 1.011. But even then, you can compile with different compilers and just link the stuff together.

I like the idea of branching, but it does the merging/backporting of patches involves quite some overhead, possibly too much for a one-man project like DMD.

L.

Lionello Lunesu wrote:
> I like the idea of branching, but it does the merging/backporting of patches involves quite some overhead, possibly too much for a one-man project like DMD.

I don't suggest branching, since Walter doesn't seem to want that.