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

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

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.

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.

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.

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

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

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.

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

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