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

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.

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.

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)

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

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.

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.

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.

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?

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.