DMD needs branches

[Russell Lewis]

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