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
