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

[1100110]

On 11/28/2012 09:32 AM, bearophile wrote:
> 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.
>
Added to my things first list.

> 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