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 :-)

Reply via email to