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.

Walter Bright wrote:
> Chris Miller wrote:
>> I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard as hell and time consuming. I need time to report bugs. Now I have to either restrict use to specific compiler versions, which people don't always know about and report their issues back to me, until I remind them they need to downgrade their compiler (which isn't always an option if they need bug fixes), or I have to rush to fix my code to workaround such issues and report bugs. If there was a stable branch, I could get the code working with the unstable branch at a reasonable pace.
> 
> 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.

What we're trying to say, I think, is that we simply need two compiler branches.

D 1.x Compiler + Documentation Branch w/ bug fixes only

D 2.x Compiler + Documentation Branch w/ features & bug fix

The problem is that folks need a compiler that is consistent and stable, and constantly adding new features to the compiler inherently undermines 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, but when developing, would rather spend our time coding D then going on bug report brigades which are seemingly entirely avoidable.

For example: even though DMD v1.0 doesn't use the 'ref' keyword, using the -v1 switch still allows you to use the 'ref' keyword and it works as expected. These types of problems, I imagine, must be more difficult to handle only having one compiler branch. With two compiler branches, these problems will never crop up in the first place.

I know two compiler branches might be more difficult to maintain and will probably consume 2x more development time on your part, but I imagine some us of just need a stable branch no matter the cost, where they can guarantee new bugs aren't added from new features that they don't even use. IMO, D seems in a constant process of keyword and feature assimilation, and D might even be benefited by simply slowing down the pace a little.

While I know you treat this simply as a technical issue, it is a psychological issue as well.

1) Big company will never adopt a language which can not /guarantee/ stability. ( or, nonprofessional coder only has time to code , not bug fix )

2) From the outside, having a compiler constantly add new features + keywords almost guarantee's the compiler won't be stable, and certainly looks like an extremely unstable language from the outside, and therefore an unstable compiler.

~ Clay

Walter Bright wrote:

> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>> 
>>> Chris Miller wrote:
>>>> I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard as hell and time consuming. I need time to report bugs. Now I have to either restrict use to specific compiler versions, which people don't always know about and report their issues back to me, until I remind them they need to downgrade their compiler (which isn't always an option if they need bug fixes), or I have to rush to fix my code to workaround such issues and report bugs. If there was a stable branch, I could get the code working with the unstable branch at a reasonable pace.
>>> 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.
>> 
>> This was said (many times!) back when the date for 1.0 was decided upon - there is no single point in making such a milestone, if there is no actual way for the user to have it enforced. One could argue that they should stick with DMD 1.000, but it has serious bugs too which has been fixed in later releases, but when these releases create new bugs (even when using the -v1 switch), then you in reality have no stable 1.0 branch. It is useless as it is.
> 
> 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.

Point is that every new feature is likely to create new bugs that will make an upgrade difficult. And as long as more new bugs appear than what is closed, your solution will not work.

You can't compare with your C++ compiler either, as it is not implementing a specification in constant flux. Using a revision system tend to make it very easy to apply just bugfixes to one branch, and new features _and_ bugfixes to the development branch.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Frank Benoit (keinfarbton) escribió:
> I think, it is not necessary to have long living stable branches.
> Only to have the bugs fixed in one version shall be applied also to the
> previous version.
> 
> Actually it is dmd 1.011
> in few week you will release dmd 1.012
> why not simple make two releases?
> dmd 1.012 only bug fixes
> dmd 1.013 bugfixes and enhancements
> 
> So there is a better chance, that more ppl can catch up.

This would be a good, simple solution, I think. Maybe not as good as having branches, but it would work.

-- 
Carlos Santander Bernal

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?

One issue mentioned last night is that the -H feature of DMD generates output containing "ref" where "inout" was in the original.  And apparently there is some sort of problem either parsing the resulting header file or linking against the implementation.  I hadn't reported this yet because it being discussed in chat when I logged off for the evening, and I haven't had time to confirm it myself.


Sean

Sean Kelly kirjoitti:
> 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?
> 
> One issue mentioned last night is that the -H feature of DMD generates output containing "ref" where "inout" was in the original.

I reported it and Walter marked it invalid. If inout is going to be deprecated in the future, I guess it's ok that way. I just wanted to point out that the programmer might have different intentions when using 'inout' and 'ref'. Then it would be important for the library user to see the correct keyword. If 'inout' is going to be removed anyway, it may not be worth the effort adding support for both. Just my 2 cents. :)

> And
> apparently there is some sort of problem either parsing the resulting
> header file or linking against the implementation.

Actually it was in rebuild. I didn't notice it didn't yet support the new syntax.

> I hadn't reported
> this yet because it being discussed in chat when I logged off for the
> evening, and I haven't had time to confirm it myself.
> 
> 
> Sean

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

Clay Smith wrote:
> Walter Bright wrote:

[snip]
> While I know you treat this simply as a technical issue, it is a psychological issue as well.
[Snip]
> 
> ~ Clay

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

-Joel

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


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Wed, 11 Apr 2007 20:01:12 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Chris Miller wrote:
>> I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard as hell and time consuming. I need time to report bugs. Now I have to either restrict use to specific compiler versions, which people don't always know about and report their issues back to me, until I remind them they need to downgrade their compiler (which isn't always an option if they need bug fixes), or I have to rush to fix my code to workaround such issues and report bugs. If there was a stable branch, I could get the code working with the unstable branch at a reasonable pace.
>
> 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.

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? Even more painful, should -v1 not apply "final" to variables? Branching would make these easier.

Actually, once I got wind that "final" was applying to variables (even before the compiler release), I went through my code and tried exluding all my variables from final attributes and released such updated code, but obviously missed a couple.

I try to be speedy about making sure my code works that others might rely upon. In some cases so fast that I anticipate it and it's fixed before it's an issue, such as when I changed my public imports literally to include "public" way before import became private by default. However, without branches, this is all very much more difficult, especially when there's little I can do to ensure my code will still work.

Plus, not everyone is or tries to be so speedy about making sure their code works, so more and more broken code ends up out there, frustrating new and old D users.

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.

- Chris