• Chris Miller (43/43) Apr 11 2007 I'm sure this was brought up in the past, but DMD definitely needs stabl...
• Frank Benoit (keinfarbton) (3/3) Apr 11 2007 Yes, thats what i also thought.
• Frederico Wagner (17/17) Apr 11 2007 I agree.
• Marcin Kuszczak (26/32) Apr 11 2007 I agree with you.
• BCS (1/1) Apr 11 2007 I second the notion, big time.
• Tyler Knott (2/2) Apr 11 2007 I'm seconding this; branches would be much appreciated for all the reaso...
• Dan (3/3) Apr 11 2007 I second branching if -v1 doesn't perfectly imitate the state of the 1.0...
• Ameer Armaly (5/48) Apr 11 2007 I agree. If D ever wants to be practically deployable in the real world ...
• Tom S (42/47) Apr 11 2007 Same here.
• Dave (11/19) Apr 11 2007 What are, say, the three major bugs that are preventing you from compili...
• Derek Parnell (7/9) Apr 11 2007 YES YES YES!
• =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= (35/37) Apr 11 2007 About the biggest problems.. I find it difficult to keep track of the
• Walter Bright (3/11) Apr 11 2007 Please let me know which issues are breaking your code. I'll be sure
• Roberto Mariottini (33/46) Apr 12 2007 I think it's not a matter of a few issues. I think the problem is in the...
• Lars Ivar Igesund (13/25) Apr 12 2007 This was said (many times!) back when the date for 1.0 was decided upon ...
• Walter Bright (14/35) Apr 12 2007 The test suite is run before every new release. If things break with a
• Frank Benoit (keinfarbton) (9/9) Apr 12 2007 I think, it is not necessary to have long living stable branches.
• Carlos Santander (5/16) Apr 12 2007 This would be a good, simple solution, I think. Maybe not as good as hav...
• Lars Ivar Igesund (13/53) Apr 12 2007 Point is that every new feature is likely to create new bugs that will m...
• Mark Wrenn (7/24) Apr 12 2007 Hmmm...Wouldn't it be cool if dsource.org ran overnight builds. This
• Clay Smith (33/46) Apr 12 2007 What we're trying to say, I think, is that we simply need two compiler
• 0ffh (2/5) Apr 12 2007 I can't see how any bug is ever going to be fixed, if nobody reports it....
• Clay Smith (2/8) Apr 12 2007 The bug will never crop up in the first place.
• janderson (6/11) Apr 12 2007 [Snip]
• Clay Smith (2/6) Apr 12 2007 It will still have the ref problem.
• Chris Miller (44/56) Apr 12 2007 ve =
• Walter Bright (7/24) Apr 12 2007 It was supposed to not do that, but there was a bug in that code. It's
• janderson (15/28) Apr 14 2007 Here's a crazy idea. Why not have all big libraries in some mega test
• BCS (2/37) Apr 14 2007 A "known good vertion" list for dsource would get much of that.
• Russell Lewis (6/11) Apr 17 2007 I think that dstress is pretty much what you're talking about; the
• torhu (22/29) Apr 12 2007 I'm also having the same problems with my D projects. I just added
• Walter Bright (2/4) Apr 12 2007 What doesn't work with 1.011?
• Sean Kelly (8/13) Apr 12 2007 One issue mentioned last night is that the -H feature of DMD generates
• =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= (9/27) Apr 12 2007 I reported it and Walter marked it invalid. If inout is going to be
• Serghei Darii (18/22) Apr 12 2007 Hi Walter,
• Chris Miller (7/28) Apr 12 2007 I added to http://www.dprogramming.com/dfl.php it includes:
• Serghei Darii (5/45) Apr 12 2007 Yes I know and I did, thank you.
• torhu (4/9) Apr 12 2007 Issue 1127 (-v1 doesn't disable the ref and macro keywords), and 1135
• Frank Benoit (keinfarbton) (3/3) Apr 12 2007 I like this proposal.
• Walter Bright (3/6) Apr 12 2007 I'm not sure what it buys, since 1.011 obviously breaks things, and I'll...
• torhu (11/18) Apr 12 2007 This is pasted from the readme.txt for my DWT app:
• Walter Bright (5/16) Apr 12 2007 I don't see any way you can avoid it, regardless of what I do. You
• Aarti_pl (7/24) Apr 13 2007 The problem is when another library has something similar in its
• torhu (17/34) Apr 13 2007 The problem wouldn't go away, but it would be greatly reduced. The
• Lionello Lunesu (6/30) Apr 13 2007 How's a post in D.announce "unleashing it on the general public"??
• torhu (15/27) Apr 13 2007 The point is that there the announcements and the version numbering is
• Lionello Lunesu (17/46) Apr 13 2007 But "stable" and "beta" are relative terms. For some people 1.011 solved...
• torhu (2/5) Apr 13 2007 I don't suggest branching, since Walter doesn't seem to want that.
• Lars Ivar Igesund (9/55) Apr 13 2007 That won't work either, at least not in that case, as the Object ABI cha...
• Falk-Florian Henrich (13/19) Apr 13 2007 I agree that any source package needs to specify some compiler/library
• Derek Parnell (8/9) Apr 13 2007 Doesn't "stable" mean "no new features - bug fixes only for existing
• Jesse Phillips (4/10) Apr 13 2007 Actually, Alpha is the new feature stage, Beta is the bug smashing stage...
• Nicolas J. (9/15) Apr 13 2007 It is true that maintaining two branches involves some more work, but:
• Nicolas J. (3/8) Apr 13 2007 I shall add that the larger the project, the more libraries one usually ...
• Walter Bright (3/8) Apr 13 2007 That is courting disaster :-(. I'd try that only as a very last resort.
• Russell Lewis (8/14) Apr 13 2007 But that is not necessary the fault of the library code themselves.
• Walter Bright (2/9) Apr 13 2007 But bugfixes themselves can cause such problems.
• Brad Roberts (10/19) Apr 13 2007 Sure, they can. That's not the issue. The issue is that a bug fix is
• Russell Lewis (15/22) Apr 13 2007 Let me say something here about "monotonically increasing stability."
• Brad Roberts (5/30) Apr 13 2007 Of course it's not an absolute requirement. Achieving it would require
• Russell Lewis (12/22) Apr 13 2007 Sort of. Obviously, bugfixes sometimes are buggy - that's just part of
• Georg Wrede (3/15) Apr 15 2007 Hmm. Then nobody should distribute compiled libraries. The -H switch
• Russell Lewis (26/31) Apr 13 2007 The problem is that this doesn't work in the real world with real
• Russell Lewis (6/6) Apr 13 2007 Sorry for using the term "real world," I hate it when people talk that
• Lionello Lunesu (6/9) Apr 15 2007 Or you could try a different compiler all-together :)
• Chris Miller (10/22) Apr 12 2007 This might be a decent compromise. At least small oversights can be fixe...
• Don Clugston (8/38) Apr 12 2007 Why not simply add a line to the download page which states 'last stable...
• David Ferenczi (9/9) Apr 12 2007 I also second this.
• Walter Bright (4/14) Apr 12 2007 The problem is that one cannot just do bugfixes without running the risk...
• Russell Lewis (20/36) Apr 12 2007 I understand what you're saying, Walter, but I don't think that what
• Dan (4/20) Apr 13 2007 Hmm... I actually like the method to his madness. : )
• Thomas Kuehne (24/27) Apr 14 2007 -----BEGIN PGP SIGNED MESSAGE-----
• David B. Held (4/12) Apr 14 2007 C'mon, Thomas! Quit making excuses and overclock that Commodore 64
• Thomas Kuehne (14/25) Apr 14 2007 -----BEGIN PGP SIGNED MESSAGE-----
• BCS (4/13) Apr 14 2007 BTW how long does it take dstress to run? I ask because I have a lexer t...
• Thomas Kuehne (10/13) Apr 15 2007 -----BEGIN PGP SIGNED MESSAGE-----
• Lionello Lunesu (4/10) Apr 15 2007 How long does it take for all tests to complete? Big difference between
• Thomas Kuehne (11/20) Apr 16 2007 -----BEGIN PGP SIGNED MESSAGE-----
• Dan (2/7) Apr 16 2007 Holy moley batman! I didn't know D had enough source to take that long ...
• Sean Kelly (3/10) Apr 16 2007 Sounds like D needs a DDStress client, kinda like SETI@Home ;-)
• Pragma (14/29) Apr 16 2007 Would that work?
• Dan (5/17) Apr 13 2007 Indeed, just post a link to 1.05 with the -v1 switch on, and label the l...
• eao197 (22/22) Apr 14 2007 There were many right words about an important role of stable branches o...
• Chris Miller (28/28) Apr 14 2007 DMD v1.012 seems good; I'm not having the issues I experienced that were...
• Nicolai Waniek (90/90) Apr 15 2007 Hello Guys,
• Nicolas J. (7/11) Apr 15 2007 Unfortunately, because it doesn't keep track of history, SVN is not very...
• Leandro Lucarella (16/27) Apr 15 2007 The problem with darcs it's it doesn't scale very well (because of
• Bill Baxter (12/32) Apr 15 2007 Grr. Why do we have to have *four* credible competitors to svn all the
• Nicolas J. (4/13) Apr 15 2007 Yes. And in fact, browsing the darcs repository online (which I suppose ...
• Bill Baxter (30/46) Apr 15 2007 That was my impression about git too, but apparently current devs are

"Chris Miller" <chris dprogramming.com> writes:

I'm sure this was brought up in the past, but DMD definitely needs stable  
and unstable branches.

-v1 doesn't cut it. My code is compiled with -v1 and still breaks with new  
DMD versions.

Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!

How am I supposed to let others use my code when there's no stability in  
the compiler? They update their compiler and report to me "your code is  
broken"; well, no, DMD is broken.

I have a ton of code that doesn't work on any of the new DMD compilers; I  
have to use an old pre-1.0 compiler, because the recent compilers are  
bug-ridden. Some bugs get fixed, but even more get added.

I'm sure a lot of you out there have similar experiences. Speak up now,  
please!

With each new release I get more and more frustrated with D. There's no  
stability! I know you want more and more features, but how can I keep  
using a language like this?

-

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.

-

D 1.0 means nothing. The 1.0 release was a huge flop. I think it could  
have done so much better and retained more users. We need some stability  
and to try the big release one more time. "D 1.1 release 'whoops, got it  
right this time'" (hopefully).

Also, the documentation should probably clearly state differences between  
versions, perhaps even with the words "unstable" near the things not in  
the stable branch. (Safe to ignore 1.0 since it's pointless.)

-

I've had all this in the back of my mind for quite some time and I've  
tried to be patient about it. I'm not trying threaten anyone, but I don't  
know how much longer I'm going to put up with D with its current methods.  
Note that I am probably one of the oldest D users still using it.

-

Thanks for your time.

- Christopher E. Miller
www.dprogramming.com
miller[] on #D freenode.

"Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

Yes, thats what i also thought.
Please do this little extra work,
it would be a really big quality enhancement.

Frederico Wagner <lectus lectus.com> writes:

I agree.
D really needs 2 branches:
* 1.x would be a bug fixes only version. (stable)
* 2.0 would be a new features and bug fixes version. (unstable, language
expansion version)

After some time, for example, 1 year, it would merge the 2.0 branch into the
stable branch and do it again. (2.x and 3.0 branches).
So users could keep using DMD until there's a new stable version, and they
could port / fix the code to be compatible with the new stable release.

If DMD stays very unstable as it is it will be forever having broken libraries,
which will slow down the development of possible frameworks and tools. Because
of this one-version-only compatibility.
And this is a bad thing for the growing of the language and the community
itself.

It's very sad to have a hard work with some project and then you find out that
it doesn't work with the new compiler version, and you have to fix this very
quickly because users want updated compilers to use with your library. With the
stable branch we would keep using it and every library would work OK.
If someone decides to use the unstable DMD version this person would do it
knowing that it may not be compatible with current libraries and source codes.

I hope the developers of D do something about this.
miller[] is really a very active user of D and is doing great work coding
libraries.
If the current problem is making he write this, I think this is a serious
problem that might be affecting other users as well.
Sorry, for my bad english. And I hope you understand what I'm saying.

Thanks.

Frederico Wagner
Lectus on #D freenode.

Marcin Kuszczak <aarti interia.pl> writes:

Chris Miller wrote:

 
 I've had all this in the back of my mind for quite some time and I've
 tried to be patient about it. I'm not trying threaten anyone, but I don't
 know how much longer I'm going to put up with D with its current methods.
 Note that I am probably one of the oldest D users still using it.
 

I agree with you. 

Additionally I think there are some really good Open Source ways of working
which are much more productive than current way of developing D. I mean
e.g. SVN repository (encourages to prepare patches), some kind of tracking
of enhancement requests (better than bugzilla), better way of packaging
compiler with standard library (I really can not get clue why linux and
windows versions of dmd are mixed in one packages; additionally breaking
packages into DMD/DMC while have same merits is not very user friendly),
more people with "write rights" for DMD/Phobos, eventually even help for
Tango people (e.g. bundling it with DMD or support in DMD for other
standard libraries not just Phobos).

I can live with current state, but I am sure that definitely using good
standards from other successfull projects would help D much more than super
hyper new features. (I am not against constness, as it look as very
important feature, but macros... well...). There are also some rough edges
in D which should be polished probably with higher priority than adding new
features...

Just a few additional thoughts...

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

BCS <BCS pathlink.com> writes:

I second the notion, big time.

Tyler Knott <tywebmail mailcity.com> writes:

I'm seconding this; branches would be much appreciated for all the reasons
other 
have posted.

Dan <murpsoft hotmail.com> writes:

I second branching if -v1 doesn't perfectly imitate the state of the 1.0
compiler.

I also second the motion for putting D development and sources on SVN - in
spite of my feelings for SVN nomenclature.

If the powers-that-be agree, then I would suggest moving it to SVN, taking the
1.0 release as-is, and then carefully merge-diff'ing it up to current for bug
fixes.

"Ameer Armaly" <ameer_armaly hotmail.com> writes:

"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.tqmzf7bzpo9bzi tanu2003.tanu2003net.local...
 I'm sure this was brought up in the past, but DMD definitely needs stable 
 and unstable branches.

 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with new 
 DMD versions.

 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!

 How am I supposed to let others use my code when there's no stability in 
 the compiler? They update their compiler and report to me "your code is 
 broken"; well, no, DMD is broken.

 I have a ton of code that doesn't work on any of the new DMD compilers; I 
 have to use an old pre-1.0 compiler, because the recent compilers are 
 bug-ridden. Some bugs get fixed, but even more get added.

 I'm sure a lot of you out there have similar experiences. Speak up now, 
 please!

 With each new release I get more and more frustrated with D. There's no 
 stability! I know you want more and more features, but how can I keep 
 using a language like this?

 -

 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.

 -

 D 1.0 means nothing. The 1.0 release was a huge flop. I think it could 
 have done so much better and retained more users. We need some stability 
 and to try the big release one more time. "D 1.1 release 'whoops, got it 
 right this time'" (hopefully).

 Also, the documentation should probably clearly state differences between 
 versions, perhaps even with the words "unstable" near the things not in 
 the stable branch. (Safe to ignore 1.0 since it's pointless.)

 -

 I've had all this in the back of my mind for quite some time and I've 
 tried to be patient about it. I'm not trying threaten anyone, but I don't 
 know how much longer I'm going to put up with D with its current methods. 
 Note that I am probably one of the oldest D users still using it.

I agree. If D ever wants to be practically deployable in the real world it 
has to be stable; coders need to have a relatively consistent compiler and 
language and say "here, this is d."
 -

 Thanks for your time.

 - Christopher E. Miller
 www.dprogramming.com
 miller[] on #D freenode. 

Tom S <h3r3tic remove.mat.uni.torun.pl> writes:

Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs 
 stable and unstable branches.

Agreed.


 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with 
 new DMD versions.

Same here.


 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!

It's even worse than this in my case. With a few friends, I'm doing a 
project for the Team Programming course at my univ. It's a First Person 
Shooter, containing more than 55k lines of our own D code plus some 200k 
of dependencies, such as DDL, Mango, Code Analyzer, Derelict, Enki, 
MinTL and various bindings. And we're stuck with... DMD 0.175. I've 
tried every single DMD release which came after 0.175, including 1.010b, 
and each has its own problems. The old bugs get slowly fixed, but new 
ones appear at a frightening pace. DMD 1.011 adds some more mixin issues 
to the pile, and even with -v1, considers 'ref' a keyword.


The worst problems with the new DMDs are codegen issues. For instance, 
http://d.puremagic.com/issues/show_bug.cgi?id=1068

Earlier, 1.007 had a weird NRVO problem. It could return garbage from 
functions when their calls appeared at the return statement. It seems to 
be gone, but no one filled a bug report and I'm not sure if it's not 
just lurking someplace else.

My team and me have first got stuck with DMD 0.175 when 0.176 changed 
the ABI and DDL stopped working for us. But then I updated DDL to the 
ABI of DMD 1.0. I can't even test it because bugs have appeared over the 
time. Some made Mango not compile, thus sending DDL to bite the dust as 
well. The latest and best one is the invalid codegen issue from the link 
above. I can't even make our game's GUI run because I'm getting random 
access violations.
After updating to DMD 1.011, I had some errors telling me about it not 
being able to find identifiers that certainly were there. Yet Another 
Mixin Bug.

D really needs to get stable before anything serious can be made in 
it... Not that I don't like the new features. The CTFE, mixins and 
smarter IFTI are just great... If only I could use them. Our project 
contains numerous workarounds for the issues in DMD 0.175 because we 
can't just report a bug and hope we'll be able to continue with the next 
DMD release. We're stuck with 0.175 and we've been stuck with it for the 
last 5 months.

I'm a huge fan of D and a long-time user, but I simply don't know what 
to tell people when they ask why we're using some archaic 0.175 version 
and not the new one with all the spiffy features. Please, fix D.


--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Dave <Dave_member pathlink.com> writes:

Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs 
 stable and unstable branches.
 
 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with 
 new DMD versions.
 
 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!
 

What are, say, the three major bugs that are preventing you from compiling code?

Don't get me wrong - I can understand your frustration (and thanks for DFL,
Entice, et al), and I'm 
not discounting your problems, but I guess I haven't seen or heard that the
newer compilers were 
more 'buggy' than the old. I thought quite a few things had actually improved
since the pre-1.0 
days. DStress (http://dstress.kuehne.cn/www/dstress.html) seems to show steady
improvement anyhow.

IMHO, since Walter is only one person, what you're asking for (branches) may
actually have the 
unintended consequence of slowing down the fixes. For many of the bugs, it
would probably require 
making mods. to two diverging code bases.

Thanks,

- Dave

Derek Parnell <derek psych.ward> writes:

On Wed, 11 Apr 2007 16:34:45 -0400, Chris Miller wrote:

 I'm sure this was brought up in the past, but DMD definitely needs stable  
 and unstable branches.

YES YES YES!

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

=?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:

Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs
 stable and unstable branches.

About the biggest problems.. I find it difficult to keep track of the
changes. The docs are now much better than what they were in 2003 when I
started using D, but they could be so much more.

There are some real problems in the current development model. First,
the DMD frontend is used by many entities (Mr. Bright, Mr. Friedman, Mr.
Richards and several others). Of course there are several pairs of eyes
also constantly hunting bugs from it. Many have created their own
installation scripts to update to a new release. Now, wouldn't it be
much easier to have a central repository for anyone to access? I mean,
although DMD 1.x is now out, it isn't so much more stable than the 0.1xx
beta releases. Maybe even create experimental branches so the community
could test patches with GDC before applying them to official DMD.

Another thing is documentation. DDOC generates nicely formatted pages
without much trouble. It should be possible to test embedded example
code by just compiling them. IIRC there have been bug reports about
examples that are not even syntactically correct. Another thing is the
pages don't currently contain metadata, e.g. version tags. This would
probably require some sort of server side wiki software. The Trac
project (although not best for pure documentation) is a good example of
this. It allows one to create reports about fixed bugs and then
cut'n'paste those to release announcements (possibly even automatically).

How could community help more? When I find a bug in the documentation
I'm not sure should I even report it. I mean, e.g. fixing a single
missing 'n' requires a lot of bureaucracy. First logging to bugzilla,
searching for previous reports, writing the report, someone reading it,
actually fixing it, and marking as fixed. It could all be done by a
(even novice) community member. Maybe sharing the user identification
info with dsource could help, allowing rw access to trusted members.

I want to thank Walter for creating D and the community for helping me
throughout the years. D is a wonderful language, but those bugs are
hurting big projects like Deadlock a lot. It's great to see high level
proof-of-concept stuff like BLADE gets attention. After all, that brings
the publicity. But please don't forget the real users with real world
projects.

Walter Bright <newshound1 digitalmars.com> writes:

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.

Roberto Mariottini <rmariottini mail.com> writes:

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.

I think it's not a matter of a few issues. I think the problem is in the 
_language_ changes.

Branching is something that works very well in many projects (the Linux 
kernel is one notable example) but also all of my  projects are 
version-based, with one branch per version.

Using CVS or Subversion makes this very easy: you make the modification 
on the main trunk, then selectively apply them to the desired branches. 
This worked flawlessly for me, saving me a lot of problems and headaches.

The STABLE branch is something old and working, without all the new 
whistles and bells, but that can compile legacy code(1). The main trunk, 
aka the UNSTABLE branch, is something new, with all the new features 
available, but possibly breaks old code.

I know that maintaining the current compiler is already a demanding 
task, but maintaining only one stable version is not that difficult. 
Simply branch the code at a particular version and keep working on the 
new code. If you find that a bug fix can also be applied to the old code 
then apply it. If fixing the bug in the old code is too much work and/or 
the bug is not applicable to the new code, then document it and say 
simply: "this is a known bug and will be fixed in the next major 
release". The change of major version can be done once a year: the 
STABLE compiler is considered OLD and no more updated, the UNSTABLE 
compiler branches becoming both the STABLE branch and the UNSTABLE main 
trunk.
This always worked for me.

Ciao

(1) What is "legacy code"?
"Legacy code" is a term often used derogatorily to characterize code 
that is written in a language or style that (1) the speaker/writer 
consider outdated and/or (2) is competing with something sold/promoted 
by the speaker/writer. "Legacy code" often differs from its suggested 
alternative by actually working and scaling. (from the Stroustrup FAQ: 
http://www.research.att.com/~bs/bs_faq.html#legacy)

Lars Ivar Igesund <larsivar igesund.net> writes:

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.

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

Walter Bright <newshound1 digitalmars.com> writes:

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.

"Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

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.

Carlos Santander <csantander619 gmail.com> writes:

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

Lars Ivar Igesund <larsivar igesund.net> writes:

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

Mark Wrenn <mark-nospam binarytheory.com> writes:

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.

Clay Smith <clayasaurus gmail.com> writes:

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

0ffh <spam frankhirsch.net> writes:

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 <clayasaurus gmail.com> writes:

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 <askme me.com> writes:

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

Clay Smith <clayasaurus gmail.com> writes:

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.

"Chris Miller" <chris dprogramming.com> writes:

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 ha=


ve  =

 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 t=


o  =

 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=3D11=
30 -  =

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 t=
o  =

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 n=
ot  =

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, b=
ut  =

obviously missed a couple.

I try to be speedy about making sure my code works that others might rel=
y  =

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 issu=
es.

- Chris

Walter Bright <newshound1 digitalmars.com> writes:

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.

janderson <askme me.com> writes:

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.


Here's a crazy idea.  Why not have all big libraries in some mega test 
suite.  You would only run this test on -v1 just before you release a 
new version (because it would take so long with 100 odd projects).  At 
the very least you could capture all the compile-time errors that way 
(and possibly runtime too).

Perhaps the D community could figure out a way to get this to you. 
Maybe they could even provide the test suit and continually add 
libraries to it themselves until it contains 100+ libraries.  It might 
even be a way to indicate which libraries work in which versions.  It 
would be updated frequently.

I guess this could kinda working like that translation system someone 
mentions a while back, which simply used a massive amount of data to get 
around the translation problem.

-Joel

BCS <ao pathlink.com> writes:

Reply to janderson,

 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.
 

 Here's a crazy idea.  Why not have all big libraries in some mega test
 suite.  You would only run this test on -v1 just before you release a
 new version (because it would take so long with 100 odd projects).  At
 the very least you could capture all the compile-time errors that way
 (and possibly runtime too).
 
 Perhaps the D community could figure out a way to get this to you.
 Maybe they could even provide the test suit and continually add
 libraries to it themselves until it contains 100+ libraries.  It might
 even be a way to indicate which libraries work in which versions.  It
 would be updated frequently.
 
 I guess this could kinda working like that translation system someone
 mentions a while back, which simply used a massive amount of data to
 get around the translation problem.
 
 -Joel
 


A "known good vertion" list for dsource would get much of that.

Russell Lewis <webmaster villagersonline.com> writes:

janderson wrote:
 Here's a crazy idea.  Why not have all big libraries in some mega test 
 suite.  You would only run this test on -v1 just before you release a 
 new version (because it would take so long with 100 odd projects).  At 
 the very least you could capture all the compile-time errors that way 
 (and possibly runtime too).

I think that dstress is pretty much what you're talking about; the 
current limitation, of course, is that it focuses on small testcases 
instead of larger libraries.  It seems like various libraries could be 
checked in (with unitests built-in) and this used as a good automated 
test suite.

torhu <fake address.dude> writes:

Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs stable  
 and unstable branches.
 
 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with new  
 DMD versions.
 
 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!

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

If the beta version is deemed too buggy, two things can happen.  The 
first being to just skip the final release for now.  And then release a 
new beta, with the usual mix of bugfixes and new features.  The second 
option is to release a new beta, with only bugfixes, but that might be 
too close to actual branching to be considered for most cases.

Hopefully, people that don't feel like living on the bleeding edge will 
choose the versions marked as 'final', and stay away from the betas. 
And people won't excpept any given library or app to compile with a beta 
version of dmd.

Walter Bright <newshound1 digitalmars.com> writes:

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?

Sean Kelly <sean f4.ca> writes:

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

=?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:

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

"Serghei Darii" <serge_ds arcor.de> writes:

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/

"Chris Miller" <chris dprogramming.com> writes:

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

Serghei Darii <serge_ds arcor.de> writes:

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

torhu <fake address.dude> writes:

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.

"Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

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.

Walter Bright <newshound1 digitalmars.com> writes:

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.

torhu <fake address.dude> writes:

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 <newshound1 digitalmars.com> writes:

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.

Aarti_pl <aarti interia.pl> writes:

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

torhu <fake address.dude> writes:

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

Lionello Lunesu <lio lunesu.remove.com> writes:

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.

torhu <fake address.dude> writes:

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.

Lionello Lunesu <lio lunesu.remove.com> writes:

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.

torhu <fake address.dude> writes:

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.

Lars Ivar Igesund <larsivar igesund.net> writes:

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

Falk-Florian Henrich <schreibmalwieder hammerfort.de> writes:

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

Derek Parnell <derek psych.ward> writes:

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

Jesse Phillips <Jesse.K.Phillips+Digitalmars gmail.com> writes:

On Fri, 13 Apr 2007 21:15:25 +1000, Derek Parnell wrote:

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

Actually, Alpha is the new feature stage, Beta is the bug smashing stage,
and Stable is supposed to have no major bug and very few bugs. Many times
betas end up getting new features.

Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:

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. <Nicolas.J. lolrofl.fakeaddress.com> writes:

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 ?

Walter Bright <newshound1 digitalmars.com> writes:

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.

Russell Lewis <webmaster villagersonline.com> writes:

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.

Walter Bright <newshound1 digitalmars.com> writes:

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.

Brad Roberts <braddr puremagic.com> writes:

On Fri, 13 Apr 2007, Walter Bright wrote:

 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.

Sure, they can.  That's not the issue.  The issue is that a bug fix is 
considerably less likely to introduce regressions than new features are.  
By separating where new features are emerging, you've got a much higher 
chance of keeping a monotomically increasing in stability release version.

If you stick with absolutes can or can't, the debate just can't go 
anywhere.  Nothing is that black or white, it's all about the shades of 
grey.

Later,
Brad

Russell Lewis <webmaster villagersonline.com> writes:

Brad Roberts wrote:
 On Fri, 13 Apr 2007, Walter Bright wrote:
 But bugfixes themselves can cause such problems.

 
 Sure, they can.  That's not the issue.  The issue is that a bug fix is 
 considerably less likely to introduce regressions than new features are.  
 By separating where new features are emerging, you've got a much higher 
 chance of keeping a monotomically increasing in stability release version.

Let me say something here about "monotonically increasing stability." 
IMHO, this is not an absolute requirement of a "stable" release.  At 
least in my company, we don't pick up new tools (compilers, etc.) 
without putting in some test on them.  If I was using dmd for work, for 
instance, I wouldn't put a new version of the compiler to production use 
until (at least) the new DStress report had come out, and I had done a 
test build with the compiler on my code.  (Plus run a few quick 
regression tests on my code built with the new compiler.)  So if there 
are new bugs in a new compiler, I simply never pick it up.  That's 
unfortunate, but not terminal.

I know that some here will disagree, but to me the essence of a "stable" 
branch is not bug-free compilers every time, but instead a reasonable 
expectation that I will eventually get my bugs fixed without having to 
simultaneously pick up new language changes.

Brad Roberts <braddr puremagic.com> writes:

Russell Lewis wrote:
 Brad Roberts wrote:
 On Fri, 13 Apr 2007, Walter Bright wrote:
 But bugfixes themselves can cause such problems.

 Sure, they can.  That's not the issue.  The issue is that a bug fix is 
 considerably less likely to introduce regressions than new features 
 are.  By separating where new features are emerging, you've got a much 
 higher chance of keeping a monotomically increasing in stability 
 release version.

 
 Let me say something here about "monotonically increasing stability." 
 IMHO, this is not an absolute requirement of a "stable" release.  At 
 least in my company, we don't pick up new tools (compilers, etc.) 
 without putting in some test on them.  If I was using dmd for work, for 
 instance, I wouldn't put a new version of the compiler to production use 
 until (at least) the new DStress report had come out, and I had done a 
 test build with the compiler on my code.  (Plus run a few quick 
 regression tests on my code built with the new compiler.)  So if there 
 are new bugs in a new compiler, I simply never pick it up.  That's 
 unfortunate, but not terminal.
 
 I know that some here will disagree, but to me the essence of a "stable" 
 branch is not bug-free compilers every time, but instead a reasonable 
 expectation that I will eventually get my bugs fixed without having to 
 simultaneously pick up new language changes.

Of course it's not an absolute requirement.  Achieving it would require 
a perfect test suite which by necessity would mean that there's no bugs. 
  I purposely said 'much higher chance of keeping a...' to indicate 
that's the goal of release branch.

Russell Lewis <webmaster villagersonline.com> writes:

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

Sort of.  Obviously, bugfixes sometimes are buggy - that's just part of 
life.  Fix 'em as you find 'em.  But a bugfix shouldn't break code that 
(from the perspective of the user) seemed to work in the past.  If so, 
then you are doing more than fixing bugs - you are now changing the 
language, and the "stable" release shouldn't do that unless there is a 
Very Good Reason.

(I know, there are pathological cases where the user is depending on the 
buggy output of the compiler, and when you fix it, he complains...but 
those users are much less interesting to me than the well-informed, 
conservative programmer, with a large project, who needs a bugfix but 
who can't pick up the latest changes to the language.)

Georg Wrede <georg nospam.org> writes:

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

Hmm. Then nobody should distribute compiled libraries. The -H switch 
just became obsolete.

Russell Lewis <webmaster villagersonline.com> writes:

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

Russell Lewis <webmaster villagersonline.com> writes:

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

Lionello Lunesu <lio lunesu.remove.com> writes:

Russell Lewis wrote:
 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?

Or you could try a different compiler all-together :)

What do you do if you'd get a ICE in Visual Studio for example? Trust 
me, I got plenty, and each time I just kept rewriting and reordering the 
code until it worked.

L.

"Chris Miller" <chris dprogramming.com> writes:

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

Don Clugston <dac nospam.com.au> writes:

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.

David Ferenczi <raggae ferenczi.net> writes:

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

Walter Bright <newshound1 digitalmars.com> writes:

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.

Russell Lewis <webmaster villagersonline.com> writes:

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?

Dan <murpsoft hotmail.com> writes:

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.

Hmm... I actually like the method to his madness.  : )

If we provide a means by which D can be thoroughly tested through and through,
then each version that he writes must conform to that test?

What if we were to then write a test suite that enforced proveable conformance
to the D specification for 1.0?  Evolving a truly complete test suite seems
more sensible than endlessly adding bug-able examples...

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan schrieb am 2007-04-13:
[snip]
 What if we were to then write a test suite that enforced provable conformance
 to the D specification for 1.0?  Evolving a truly complete test suite seems 
 more sensible than endlessly adding bug-able examples...

You are welcome to do so. However the only sensible way to do so would
be to use formal specification to generate the tests. While this is a
relatively trivial task for the syntax tests (especially the no-compile
target) runtime tests will require a serious amount of work.

DStress[1] at least (don't know about Walter's test suite) contains quite a
number of pro-active test cases. I simply haven't gotten around to add
tests for the post DMD-1.004 features.

Another problem is the processing power required to run those tests.
e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
resulting in 213324 tests. In total that resulted in ca. 214000 compiler
invocations, 138000 linker invocations and ca. 137500 executions of
newly generated executables.

Thomas

[1] http://dstress.kuehne.cn

-----BEGIN PGP SIGNATURE-----

iD8DBQFGIK11LK5blCcjpWoRAtdiAJ4zftd2EdejPrH/9d4H4qwNwcVJTwCfY10D
I7E+6myEksiY/zwpV0ekN2U=
=BOPN
-----END PGP SIGNATURE-----

"David B. Held" <dheld codelogicconsulting.com> writes:

Thomas Kuehne wrote:
 [...]
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.
 [...]

C'mon, Thomas!  Quit making excuses and overclock that Commodore 64 
already!!

Dave

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David B. Held schrieb am 2007-04-14:
 Thomas Kuehne wrote:
 [...]
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.
 [...]

 C'mon, Thomas!  Quit making excuses and overclock that Commodore 64 
 already!!

My test system is Turion 64 clocked at 1.6GHz with 2GB RAM. However the
tests only run with "nice -n 18" in the background thus donating hardware
might help. And yes, the testsuite has no trouble to keep all cores
in a N-cpu system (with 1 <= N <= 6000) busy.

;-P

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFGIS/yLK5blCcjpWoRAkfCAJ9IlkaaS1Pfhqmt9RpYND8txpbdTQCgoKYc
TXW3uGunf+hhBuO4JPOWD0M=
=jRXT
-----END PGP SIGNATURE-----

BCS <ao pathlink.com> writes:

Reply to Thomas,

 My test system is Turion 64 clocked at 1.6GHz with 2GB RAM. However
 the
 tests only run with "nice -n 18" in the background thus donating
 hardware
 might help. And yes, the testsuite has no trouble to keep all cores
 in a N-cpu system (with 1 <= N <= 6000) busy.
 ;-P
 
 Thomas


BTW how long does it take dstress to run? I ask because I have a lexer that 
is able to lex almost all of the compile branch (~4700 files) in just over 
a minute. I'm wondering how this compares to DMD.

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BCS schrieb am 2007-04-14:
 BTW how long does it take dstress to run? I ask because I have a lexer that 
 is able to lex almost all of the compile branch (~4700 files) in just over 
 a minute. I'm wondering how this compares to DMD.

I've send you a stubbed DMD-1.011 frontend (too large for posting here).

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFGIdK1LK5blCcjpWoRAtLUAJ0fP7XTJSSwo2Cnk9IpJzXA8TqrtgCgipSs
sc9JIKFjyB531b60LQlsERk=
=Hlvc
-----END PGP SIGNATURE-----

Lionello Lunesu <lio lunesu.remove.com> writes:

Thomas Kuehne wrote:
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.

How long does it take for all tests to complete? Big difference between 
GDC/DMD?

L.

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lionello Lunesu schrieb am 2007-04-16:
 Thomas Kuehne wrote:
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.

 How long does it take for all tests to complete? Big difference between 
 GDC/DMD?

If the testsuite is the only running application and neglection dead
locks: ~ 25 hours for DMD, ~ 36 hours for GDC

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFGIz9OLK5blCcjpWoRAkDcAJ9aY6qITQvtED3Ox6j+3+QiXH4wWACgmPad
lWbczCH+9Jfzg2QZHbBtrzc=
=J6/U
-----END PGP SIGNATURE-----

Dan <murpsoft hotmail.com> writes:

Thomas Kuehne Wrote:
 How long does it take for all tests to complete? Big difference between 
 GDC/DMD?

 
 If the testsuite is the only running application and neglection dead
 locks: ~ 25 hours for DMD, ~ 36 hours for GDC

Holy moley batman!  I didn't know D had enough source to take that long to do
*anything* to it.  I could almost manually retype my entire scripting engine in
that much time!

Sean Kelly <sean f4.ca> writes:

Dan wrote:
 Thomas Kuehne Wrote:
 How long does it take for all tests to complete? Big difference between 
 GDC/DMD?

 If the testsuite is the only running application and neglection dead
 locks: ~ 25 hours for DMD, ~ 36 hours for GDC

 
 Holy moley batman!  I didn't know D had enough source to take that long to do
*anything* to it.  I could almost manually retype my entire scripting engine in
that much time!

Sounds like D needs a DDStress client, kinda like SETI Home ;-)


Sean

Pragma <ericanderton yahoo.removeme.com> writes:

Sean Kelly wrote:
 Dan wrote:
 Thomas Kuehne Wrote:
 How long does it take for all tests to complete? Big difference 
 between GDC/DMD?

 If the testsuite is the only running application and neglection dead
 locks: ~ 25 hours for DMD, ~ 36 hours for GDC

 Holy moley batman!  I didn't know D had enough source to take that 
 long to do *anything* to it.  I could almost manually retype my entire 
 scripting engine in that much time!

 
 Sounds like D needs a DDStress client, kinda like SETI Home ;-)
 
 
 Sean

Would that work?

0) download client
1) client runs and syncs with stress-test repository
1.1) client syncs compiler distribution(s) for needed tests
1.2) client gets list of incomplete test cases
1.3) client syncs stress-test code for needed test cases
2) client runs needed tests
3) client reports results
4) sleep while not idle
5) (system idle) loop to 1

That might work a treat for performance testing of discrete code samples, if
nothing else.

-- 
- EricAnderton at yahoo

Dan <murpsoft hotmail.com> writes:

janderson Wrote:

 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.

Indeed, just post a link to 1.05 with the -v1 switch on, and label the link
"Stable Release" and never take it down.  : )

That's pretty much all people are asking for - is that stable release link they
can have people click on that won't change.  If a bug is identified in that
stable release, don't fix it, just document it.

Later, when you get up to 1.2, change the link to "Stable Releases" and release
1.2.3 or whatnot.

Problem solved?

eao197 <eao197 intervale.ru> writes:

There were many right words about an important role of stable branches of  
D compiler in big ("real-world") projects. I can understand the people who  
use D for long time and have big amount of code, but I'm in the different  
situation -- I just have started my switching from C++ to D. And for me  
the changes in D after v.1.000 are much more valueable then the fact of  
passing 'v.1.000 milestone'. IMHO, the next D version, 2.0 with  
const/final/invariant and AST macroses, can make D more powerful and  
attractive language. So I want see high speed of D evolution now and such  
speed of language changing makes separation of D to 'stable' and  
'unstable' versions undesirable at the current time (from my point of  
view). But that question is going to be actual when D will reach some  
limit in his evolution. When Walter Bright will have said: "There isn't  
any new feature I want add to D". That will be point of the language  
stabilisation.

So I want to ask Walter:

Do you see any visible limit in D evolution? Do you known the moment after  
that you will say: "It's time to stop add new features to languages and  
start collect user expirience after several years of stable language  
version usage"?

-- 
Regards,
Yauheni Akhotnikau

"Chris Miller" <chris dprogramming.com> writes:

DMD v1.012 seems good; I'm not having the issues I experienced that were  
introduced in v1.011.

I also decided to test my code that was having some memory garbage  
collected too early if I didn't use std.gc.setV1_0() and the problem seems  
fixed now (without the v1.0 call). I haven't been testing this particular  
issue with all the recent releases, so it was probably fixed a few  
versions ago.

"Bug ridden" isn't so accurate, as I previously phrased; sorry about that.  
I was actually referring to the earlier 1.0 versions, and then this v1.011  
released with breaking issues. DMD v1.012 seems considerably more stable  
than those earlier 1.0 versions.

I still think something needs to be done to minimize instability, even if  
it's just the previously proposed one-week-early prerelease to catch  
obvious slip-ups. A prerelease/beta page can have a specific date that it  
will go public, so users know exactly when they have to report their  
issues without it being too late. Any reported and fixed issues will cause  
the prerelease to be replaced and the date will probably be reset to be  
another week from that day. An upside to the prereleases is you don't need  
to keep them available beyond their prerelease lifetime.

How the current dmd.zip is only referring to 1.010 is not enough, although  
I appreciate the effort. A lot of people, including myself, download from  
the changelog and/or expect to get the top version. I think a separate  
branch or prerelease will at least put people into a different mindset  
about new versions, because there will be a clear separation.

Also, the prereleases can be used to try out new stuff, which can say  
there is no planned release time. E.g. that regex syntax that popped up  
for a version or two.

- Chris

Nicolai Waniek <no.spam thank.you> writes:

Hello Guys,
At the moment I'm not using D because I have no project that depends on it
(there is just a small python project in my spare time currently) but I'm
following all the discussions here about "branching" and "documentation" and
"buggy versions" and all the stuff and having professional experience with a
huge project (>1.500.000 LOC) having some problems like that and having to
integrate better bug-fixing mechanisms and so on, I would like to participate in
the discussion this time and provide some knowledge I have, though I don't know
if it suits to a 1-man-project like D is, but here are my thoughts:



I. Branching and why it is good - but more work to do

I.1 The long story

Our project was huge and there were lots of bugs in it because it based on an
old project and we couldn't dump it and begin at zero. Due to managment
problems, the software was released early and we had no "betas" - it event went
so far I was ashamed to release a version in such an unstable state. Long story
short, we Developers had to grab the steering wheel and provide more stable
versions because management just ignored what we were saying. So the first step
was to simply branch the project. We were a very small team so I know why Walter
just does not to take this step: It involves everyone in much work. The "old
branch" was just for bugfixing purposes sharing some code with the "new branch"
that got all the new features. Our customers liked it that way because though
they had to wait longer for a new feature, the version they used got stable. We
even branched it again, so that we had three branches:

1. stable, release build (called "release")
2. unstable with few new features to be tested ("beta")
3. _very_ unstable with all the new shiny things we could think of. ("unstable")

The first one, the stable branch, was that version of the software our customers
used. They got a new version about every 4 weeks.
The second version was the one with bugfixes for the "stable" on to be tested
yet and with few features that we thought were stable enough to be but from
branch "unstable" to this one.
The third branch was the one with all the new features, but heavily unstable and
- of course - untested (because developer's always exactly know what to do to
don't get exceptions, though this might not be intentionally done!).

This was lot's of work to be done, because (as mentioned above) we were a very
small team. Everyone had to do some bugfixing for the stable one. These fixes
where checked into branch "beta". When a feature of branch "unstable" was
finished and succeeded our tests, it was moved to branch "beta". "beta-versions"
were released very often because our software was used in our company, so we had
 about 20 beta-testers and hotfixes for the beta version could be done quickly
and - even better - deployed quickly to our beta-testers (it usually took less
than an hour when there was a nasty bug in the beta to be fixed). Nevertheless,
when the new features that were included into the beta were somewhat stable, we
called in a "feature freeze" and there were no changes to the beta anymore than
bugfixes for about 1-2 weeks. When this timespan passed by, the beta was
hardened enough to become the new "stable" version.

In the long run, branching was hard to do in the beginning, but it improved
heavily the stability of our software and even improved development speed
because we could concentrate on the task to be accomplished and not on "oh, when
I do this, it might break that" (because we knew a new feature won't be released
tomorrow ;) ).


I.2 How to adopt to D?

Well this might be a nice story but you might ask "what the heck does this have
 to do with D"? Your question is legitimate, but it shows how Walter could
change its development style, even when he's the only developer:

- Have a "stable" branch, that is, the one everyone should use for their real
world projects.
- Have a "beta" branch where all the bugfixes for the stable branch are
incorporated into and new features you think they are stable enough to be
published
- Have an "unstable" branch were you can doodle around with everything you ever
wanted to do with the D compiler ;) When you think, feature "x" is worth it,
move it to D.
- Think of "release cycles", like "there's a bugfixed and labeled "stable" D
compiler every 3 weeks". This could be done this way: 2 weeks for new features
to be pushed into "beta", then feature freeze and afterwards one week of "beta
testing" (and I bet there are lots of D users that will participate!). During
this week, you might bugfix the nastiest bugs and then release the stable one. I
don't know how much time you have, so you might change the times from 3 weeks to
4,5,... whatever.

You don't need real branches for that, you may even just copy the source files
from one directory to another, but having a backend like SVN doing it will save
you lots of work to be done (e.g. you could share some source files through all
branches when you're certain that they won't get changed).




II. Documentation

In my opinion, documentation could be done by the community. There should be
more examples, tutorials, or whatever bundled with D when downloading so a user
does not have to navigate to 4dwiki, or whatever. This could be done by the
community itself, so no work for you: If someone has the urge to write a
tutorial/help file, just do it and the community could rate it. Simple example:
Someone writes an article about CTFE in D. The community has the possibility to
rate it from 0 (bad) - to 5 (superb). After two weeks, the article has an
overall rate of 4.3, so it's not that bad and you'll incorporate it into the
help files. Something like this... but one has to think of a number an article
has to achieve to become part of the help files (e.g. 3.75 or 4).



These are just some ideas and my opinion about "how one might do things". so
take them up and improve them, where you think something could be done better/in
another way and let us know. :)

(and with "you" I don't only address Walter, but everyone)


best regards,
Nicolai

Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:

Nicolai Waniek Wrote:
 You don't need real branches for that, you may even just copy the source files
 from one directory to another, but having a backend like SVN doing it will save
 you lots of work to be done (e.g. you could share some source files through all
 branches when you're certain that they won't get changed).

Unfortunately, because it doesn't keep track of history, SVN is not very good
at merging, so that it gives a little more work for the maintenance of several
parallel branches, even though it still reduces the work of reporting patches
by maybe 80%.

More powerful tools like darcs and mercurial reduce the number of merge
conflicts (and therefore manual work) greatly. darcs has a very interesting
concept of dependencies between patches that allow to undo a patch easily: i.e
it is possible to remove a patch and the SCM will remove all the patches that
were dependent on it.

Decentralized SCM like those ones are better suited to open source software
than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to
connect to the central server to be able to work. In this model, each developer
has a complete local copy of the central repository, so that he can work
offline. He only connects to it to synchronize, so this model scales better
than the centralized model.

A google tech talk of presentation of mercurial:
http://video.google.com/videoplay?docid=-7724296011317502612

(but of course, it's up to Walter to decide what he is up to...)

Leandro Lucarella <llucax gmail.com> writes:

Nicolas J., el 15 de abril a las 13:51 me escribiste:
 Nicolai Waniek Wrote:
 You don't need real branches for that, you may even just copy the source files
 from one directory to another, but having a backend like SVN doing it will save
 you lots of work to be done (e.g. you could share some source files through all
 branches when you're certain that they won't get changed).

 
 Unfortunately, because it doesn't keep track of history, SVN is not very good
at merging, so that it gives a little more work for the maintenance of several
parallel branches, even though it still reduces the work of reporting patches
by maybe 80%.
 
 More powerful tools like darcs and mercurial reduce the number of merge
conflicts (and therefore manual work) greatly. darcs has a very interesting
concept of dependencies between patches that allow to undo a patch easily: i.e
it is possible to remove a patch and the SCM will remove all the patches that
were dependent on it.
 
 Decentralized SCM like those ones are better suited to open source software
than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to
connect to the central server to be able to work. In this model, each developer
has a complete local copy of the central repository, so that he can work
offline. He only connects to it to synchronize, so this model scales better
than the centralized model.

The problem with darcs it's it doesn't scale very well (because of
implementation issues, they say). I love darcs for small projects, but
(sadly) it's not really suitable for big ones yet.

Another great (distributed) SCM is git, done by Linus Tolvards for
maintaing the Linux kernel (a really big project, as you know, so it
scales by design).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
 .------------------------------------------------------------------------,
  \  GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05 /
   '--------------------------------------------------------------------'
Soñé que tenia un caballo
Que me trataba mejor que vos
Tenia tan buena onda con ella
Era mi yegua, mucho mas que vos

Bill Baxter <dnewsgroup billbaxter.com> writes:

Leandro Lucarella wrote:
 Nicolas J., el 15 de abril a las 13:51 me escribiste:
 Nicolai Waniek Wrote:
 You don't need real branches for that, you may even just copy the source files
 from one directory to another, but having a backend like SVN doing it will save
 you lots of work to be done (e.g. you could share some source files through all
 branches when you're certain that they won't get changed).

 Unfortunately, because it doesn't keep track of history, SVN is not very good
at merging, so that it gives a little more work for the maintenance of several
parallel branches, even though it still reduces the work of reporting patches
by maybe 80%.

 More powerful tools like darcs and mercurial reduce the number of merge
conflicts (and therefore manual work) greatly. darcs has a very interesting
concept of dependencies between patches that allow to undo a patch easily: i.e
it is possible to remove a patch and the SCM will remove all the patches that
were dependent on it.

 Decentralized SCM like those ones are better suited to open source software
than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to
connect to the central server to be able to work. In this model, each developer
has a complete local copy of the central repository, so that he can work
offline. He only connects to it to synchronize, so this model scales better
than the centralized model.

 
 The problem with darcs it's it doesn't scale very well (because of
 implementation issues, they say). I love darcs for small projects, but
 (sadly) it's not really suitable for big ones yet.
 
 Another great (distributed) SCM is git, done by Linus Tolvards for
 maintaing the Linux kernel (a really big project, as you know, so it
 scales by design).
 

Grr.  Why do we have to have *four* credible competitors to svn all the 
sudden? (Mercurial, Git, Darcs, Monotone)  When SVN came out it was a no 
brainer.  Better than CVS: check.  Anything else better than CVS and 
still free?  Nope.  Ok, SVN it is then!  But now we have to deal with 
*four* credible challengers to SVN.  Can somebody please tell me which 
three of those projects are destined for the also-ran bucket so I don't 
have to waste any time learning them?

[Mostly kidding -- choice is great, competition is great.  I just wish 
there were one that blew the others so totally out of the water that it 
would be a no-brainer]

:-)

Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:

Leandro Lucarella Wrote:

 The problem with darcs it's it doesn't scale very well (because of
 implementation issues, they say). I love darcs for small projects, but
 (sadly) it's not really suitable for big ones yet.
 
 Another great (distributed) SCM is git, done by Linus Tolvards for
 maintaing the Linux kernel (a really big project, as you know, so it
 scales by design).
 
 -- 

Yes. And in fact, browsing the darcs repository online (which I suppose is
managed by darcs) is a pretty painful experience.
http://abridgegame.org/cgi-bin/darcs.cgi/darcs/

git is hardly an option beacuse it is non-portable (it takes advantages of
optimizations for the Libux kernel, from what I gather,  so it's not going to
be ported soon), and it has some usability issues due to design choices of its
author ("renaming files is not important"). I believe mercurial would be a much
better option, as it is said to scale very well. And it also has the
Clearcase-like merge with history.

Anyway, this is probably not the right moment to continue discussing things
like this.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Nicolas J. wrote:
 Leandro Lucarella Wrote:
 
 The problem with darcs it's it doesn't scale very well (because of
 implementation issues, they say). I love darcs for small projects, but
 (sadly) it's not really suitable for big ones yet.

 Another great (distributed) SCM is git, done by Linus Tolvards for
 maintaing the Linux kernel (a really big project, as you know, so it
 scales by design).

 -- 

 Yes. And in fact, browsing the darcs repository online (which I suppose is
managed by darcs) is a pretty painful experience.
http://abridgegame.org/cgi-bin/darcs.cgi/darcs/
 
 git is hardly an option beacuse it is non-portable (it takes advantages of
optimizations for the Libux kernel, from what I gather,  so it's not going to
be ported soon), and it has some usability issues due to design choices of its
author ("renaming files is not important"). I believe mercurial would be a much
better option, as it is said to scale very well. And it also has the
Clearcase-like merge with history.
 
 Anyway, this is probably not the right moment to continue discussing things
like this.

That was my impression about git too, but apparently current devs are 
more interested and open about win32 issues.  Also you can now get a 
precompiled git for windows via Cygwin whereas before the answer I got 
was something like "yeh, you should be able to compile it on Windows 
with cygwin, no prob".

The inkscape devs have pretty much decided to go with Git.  I cried 
"noooooo" like you, because my experience had been that Git was for 
Linux and Unix.  Period.  End of story.  But they say it's not so.  And 
Git is the only SCM to have Google SoC projects, so that seems like it 
says something about how much they've got their act together.  Plus it 
does have that whole Linux seal of approval, so it's not going away any 
time soon.

The UI issues I don't know much about, but I gather that's what 'cogito' 
is for -- to put a user-friendly svn-like face on git.

Now may not be the best time to discuss it for D, per-se, but I'm tired 
of not being able to do commits when I'm home or traveling, and I'm 
ready to switch to one of these fancy distributed thingamajigs.  I just 
can't tell which one because none of those projects will come right out 
and say honestly "<Project> -- We're not as good as <X>,<Y>, and <Z>, 
but we're usable!"

Like the darcs performance thing.  Never heard that before.  But that 
plus the idea being kooky to begin with (source code control based on 
"quantum theory" -- uh, yeh, whatever)  sound like good enough reasons 
to drop it off the list. :-)  Now what about the other two?  :-)  Gaim 
(now Pidgin) just announced a move to Monotone, and I assume someone 
looked carefully into that choice.

Here's something that would matter to me -- which one has the best tools 
for migrating from svn?  Anyone know?

--bb