On Dec 16, 2013, at 1:24 PM, Stefan Seefeld
My main concern with the current numbering scheme is that the current 'major' number is entirely meaningless. There is absolutely no concern for compatibility between releases 1.X and 1.(X+1), so making a distinction between 'major' and 'minor' seems a little pointless.
You make an excellent point, but a future release that forgoes C++98/03 altogether, would certainly warrant a major version number bump. However, if we can't agree on such a break a priori, I suspect it won't happen. If we agree to take that direction, then using 2.x to indicate modularization, or even just the Git transition, isn't out of the question.
Thus I think that a switch to 2.0 would reinforce a notion of a metric that doesn't exist.
Maybe not, after all.
Thus, I'm still thinking that the best change in numbering would be to remove the '1.' prefix (and it really is nothing but a common prefix !), and continue to number with a 'flat' scheme N, N+1, N+2, ...
So, the next version would be 56, not 1.56. And if there is a need for a 'minor bugfix release', that could then be captured in an exceptional 56.1 number. But please, get rid of the redundant leading '1.' !
That makes a lot of sense should we choose to skip using the major version to indicate language transitions. ___ Rob (Sent from my portable computation engine)