DMD 2.1.0?

bearophile bearophileHUGS at lycos.com
Mon Jul 23 09:30:21 PDT 2012


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


More information about the Digitalmars-d mailing list