Given:
- The many differences between dmd 2.059 and 2.060alpha, and the
amount of time passed since the release of 2.059;
- The fact that there are some 2.060alpha regressions to be fixed
still, so dmd 2.060 is not coming out tomorrow;
- And the recent idea of introducing stable dmd releases that
include many patches despite not being really a v.2.061 (see the
"Stable D Releases!" in D.announce);
- That I think a "languageNumber.majorVersion.revision" numbering
scheme is better, more widespread and more useful (where
"languageNumber" is 1, 2 and maybe 3, a change in "majorVersion"
means something is changed in the language and this calls for
changes in user code and this is the point where the stable D
releases must include all the patches of the main trunk, and
"revision" means just bug fixes and tiny backwards-compatible
enhancements that are not necessarily included in the stable D
release) (See: http://en.wikipedia.org/wiki/Software_versioning ).
Then I suggest to call the next release dmd 2.1.0 :-)
And maybe in such 2.1.0 it's better to deprecate the features
marked as "future" here:
http://dlang.org/deprecate.html
In a Bugzilla entry (6277) I have also suggested another idea
(maybe fit for dmd 2.1.0 still) to improve the evolvability of
the D language: beside using -d (deprecated features) another way
to face those problems is to use an idea from Python, a switch
like "-future" that activates language features that will be
introduced in future (this also means the "-property" flag gets
moved into "-future" and removed, so the total amount of dmd
flags doesn't change).
Bye,
bearophile
