DMD 1.030 and 2.014 releases

[Robert Fraser]

Lutger wrote:
> Implementing 'changes' like the currently discussed one that don't have much
> impact or are actually clarifications from the spec is one thing. But
> adding new features, even if backward compatible, may introduce again the
> situation that libraries grow out-of-sync.

I'd hope the features selected would be such that most D libraries would 
still be able to compile. For example, Java is _mostly_ backwards 
compatible to 1.0 (if you take out the "enum" and "assert" keywords, 
it;s likely that 1.0 code would compile fine under 1.6). I'd hope the 
same is true of D if it gets a 1.1 branch (that is, if any new features 
are added, they are done in a way that DOES not keep libraries out-of-sync).

If it was designed in a way to keep a large, mostly-spanning subset of 
(multiple versions of) D1 libraries/apps (i.e. Tango, Phobos, DFL, DWT, 
Derelict, MiniD, a few other big ones) compiling at every release, it 
would be reasonable to assume that most D1 code would compile rather 
easily with it. I'd also hope that any DStress tests that pass with D 
1.030 (or whenever the branch is made) would remain a strict subset of 
the DStress tests that pass as the branch evolves.

If these conditions were met, it would be possible to add in *some* 
backwards-compatible changes that would benefit the community and still 
allow libraries designed for the 1.0 branch to keep compiling. But 
that's just my personal pipe dream: I'm sure some people wouldn't mind 
having 3 completely distinct branches, while others would prefer that 
only bugfixies make it into 1.1.