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.
>
> 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

A monthly 'beta' with a twice yearly stable release sounds good to me.

It would be even better if we had a tool that attempted to automatically 
fix minor breaking changes. (for the stable of course.)

To use an example from another thread, func(auto const ref var) doesn't 
work, but func(auto ref var) does.  It would be relatively trivial to 
strip the const if that was one of the breaking changes.