Breaking D2 language/spec changes with D1 being discontinued in a month

[bearophile]

Walter Bright:

> I can see creating a stable D2 and a forward D2 for 6 months at 
> a time or so, as has been proposed here. I think that's a good 
> idea. But only after D1 is no longer supported.

I am OK with such ideas. Below there are some musings.

How do you want to call (release numbers) those two D2 versions 
(Stable-D and Development-D)? I prefer a simple Python-like 
numbering scheme, where the second digit denotes significant 
changes (every 6 months?) and the third digit (plus alpha, beta, 
rc1, rc2, rc3, ... suffixes) refers to bug fixes that don't break 
much code. I think such numbering scheme is also able to make D 
look a little more mature and a bit more "professional".

I also think it's a bad idea to create a "D3", at the moment. 
This means I suggest to eventually merge in the Stable-D all the 
changes of Development-D (unless testing of the Development 
version shows that it's better to abandon an idea in both D2 
branches).

I suggest to release Development-D quite often, like every 20-35 
days, if it's possible.

The presence of Development-D should allow for a more relaxed 
development, bug fixing and more. There are several things to 
fix. One of such possible changes is to remove the inliner from 
the D front-end (because ldc2 and gdc2 don't use it). Making the 
front-end a slimmer is good. There are other changes worth 
considering, like aligning D ABI and function calls (as other 
compilers refuse or can't do those things). LDC2 will be probably 
quite used on Windows64bit.

Patches for Development-D should work in both D2 versions, unless 
the changes are about features not yet present in Stable-D.

For simplicity I think the first thing to do to go toward the 
first Stable-D version should be strip away the D1 parts from the 
D2 Git sources, to clean and shorten the D2 code and make its 
updates simpler.

As others have said I think it's better to not keep a single 
Development-D trunk, but branch it when new features (or 
significant changes) are developed (like UDA).

Bye,
bearophile