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.
