D versionning

[Joseph Rushton Wakeling]

On 16/07/12 01:42, Jonathan M Davis wrote:
> I'm only against the proposed versioning scheme because I think that we need
> to stabilize things better (e.g. actually have all of the features that TDPL
> lists fully implemented) before we move to it. But I fully support moving to
> this sort of scheme in the long run. It manages change much better, and I
> think that many, many existing projects have shown that it promotes stable
> code bases while still allowing for them to evolve as necessary.

... but is a switch to this versioning method really going to slow down the 
implementation of new features?

D is now stable enough (in terms of quality) and broad enough (in terms of 
features) for this scheme to be useful, so perhaps it's worth defining the 
"blocking" features that really _must_ be there before a switch in versioning 
style takes place.

I think that should probably be a minimal rather than maximal list, with the aim 
being to switch versioning style sooner rather than later.  It shouldn't have to 
wait on everything that TDPL lists -- how long is that going to take?

If you want the version number scheme to represent clearly the importance of the 
complete-TDPL milestone, how about instead bumping the MAJOR version number when 
it's done?  Yes, I know much has been said about "no D3", but this is a 
different and possibly useful definition of 3.0 :-)