Lionello Lunesu wrote:

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

That won't work either, at least not in that case, as the Object ABI changed with 1.010. The latest stretch of compilers have just been a long line of incompatible releases.

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

Am Fri, 13 Apr 2007 13:21:50 +0300 schrieb Lionello Lunesu:

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

I agree that any source package needs to specify some compiler/library requirements. Nevertheless, I do not know of any quality open source software that has dependencies of the type

gcc == 3.3.3
libXYZ == 2.3.4
libABC == 1.0.7

Real world packages only specify something like

libXYZ >= 2.3.4

If you want people to download and use your software you cannot bother them with awkward dependencies. Sad to say, but at this point of time, D seems to be light years away from that level of interoperability.

Falk

On Fri, 13 Apr 2007 13:21:50 +0300, Lionello Lunesu wrote:

> But "stable" and "beta" are relative terms.

Doesn't "stable" mean "no new features - bug fixes only for existing features" and "beta" means "new features are to be expected".

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

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

It is true that maintaining two branches involves some more work, but:

1. because a STABLE branch is not supposed to introduce new bugs (in theory), Walter doesn't have to work in a hurry because of possible regressions that create havoc in some users' projects, like he is doing right now.
So he can work more peacefully on new features, as people who work with the bleeding edge versions do expect some broken code, and therefore don't complain (but they can report bugs).

2. a STABLE branch offers the chance for people to actually contribute to bug fixing. It's hardly the case with a constantly evolving compiler, as one bug fix may just be out of date in the next version. This discourages people to actually contribute to bug fixing.

So this overhead could be compensated at least partly by more involvement of the community members to the improvement of the overall quality of at least the STABLE branch.

For everybody, this would be a huge bonus in stability and quality, not only of the compilers, but also of the whole codebase, since library writers can rely on the stable version.
The top 5% expert coders will happily work with the bleeding edge evolutions.
But for the rest of us, the language may very well be "good enough" right now, but what may prevent people from engaging into large scale projects in D is no longer issues with the expressiveness of the language or the lack of tools (today code::block  fills the bill quite nicely) than the uncontrolled risks of incompatibilities between libraries.

Nicolas J. Wrote:

> 
> For everybody, this would be a huge bonus in stability and quality, not only of the compilers, but also of the whole codebase, since library writers can rely on the stable version.
> The top 5% expert coders will happily work with the bleeding edge evolutions.
> But for the rest of us, the language may very well be "good enough" right now, but what may prevent people from engaging into large scale projects in D is no longer issues with the expressiveness of the language or the lack of tools (today code::block  fills the bill quite nicely) than the uncontrolled risks of incompatibilities between libraries.
> 

I shall add that the larger the project, the more libraries one usually relies on, and the higher the risks of incompatibilities. It is not uncommon for a 20,000 lines project to rely on 5 or 10 libraries. What is the probability to find 10 libraries compatible with each other and with the latest compilers in the D codebase right now ?

Lionello Lunesu wrote:
> 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.

The problem is that this doesn't work in the real world with real projects.  Imagine that you have a gigantic project (100,000 lines or more), and late in the game you stumble across some small (but important) bug.  You work on it, and finally realize that the root cause is in the compiler: it is producing incorrect code, or whatever.

You post a bug, and the response is, "This bug was fixed in version 1.2.3.4."  Problem is, 1.2.1.2 introduced a major change to the language which will break 1000s of lines of your code.  Or, worse yet, there have been many small changes to the language...and you don't know if they would break your code or not.  If you pick up the new compiler, you must first test build the entire project, then start your test over, pretty much from scratch, in order to confirm that nothing is subtly broken. This isn't going to happen.

So what do you do now?  Do you rewrite your whole project so that you can pick up the new compiler?  Do you find some sort of hackish workaround in your code to avoid the bug?

I face this problem all the time at work.  We have released a large, expensive product to the field.  We have customers who hit bugs (and our QA department, while reduced in size, is still active and finding new bugs).  We are required to fix these bugs and periodically release new versions of the microcode...but we must never break what "works" in the field.  Breakage is the Cardinal Sin of my development group.  Every new (or changed) feature in D is potentially Breakage, which is why, IMHO, somebody (perhaps not Walter) needs to maintain a "stable" branch.

Russ

Lionello Lunesu wrote:
> 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.

Unfortunately, I feel that makes the libraries unusable with each other.

> But even then, you can compile with different compilers and just link the stuff together.

That is courting disaster :-(. I'd try that only as a very last resort.

Sorry for using the term "real world," I hate it when people talk that way.  All I am trying to say is that while the current release style for dmd is good for some things (I love to use D at home), it is insufficient to support large-scale, high-requirement projects, like what I have to do at work.

Russ

Walter Bright wrote:
> Lionello Lunesu wrote:
>> 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.
> 
> Unfortunately, I feel that makes the libraries unusable with each other.

But that is not necessary the fault of the library code themselves. Perhaps one of them can't use an old compiler because there is a compiler crash, and one can't use a new compiler because it uses a syntax (or keyword) that used to be valid but is now not allowed.  If there was "stable" branch of the older compiler, that included the bugfix but not the language change, then both libraries would work together just fine.

Russell Lewis wrote:
> But that is not necessary the fault of the library code themselves. Perhaps one of them can't use an old compiler because there is a compiler crash, and one can't use a new compiler because it uses a syntax (or keyword) that used to be valid but is now not allowed.  If there was "stable" branch of the older compiler, that included the bugfix but not the language change, then both libraries would work together just fine.

But bugfixes themselves can cause such problems.