> At the risk of racing too far ahead in this discussion, here is my suggestion... > 2.0.43 becomes 2.1 and the MMN major does not change for subsequent 2.1 series > releases (except for a compelling reason, eg a security fix -requires- a bump). Why > 2.1? No technical reason; purely a PR tactic to telegraph to the user community we > are putting a lot of focus on maintaining binary backward compatability and to get > rid of the *.0.* in the version number (yea, to appease the folks who are allergic to > 0's in version numbers).
> New ROADMAP development is started in 3.0. <thunderous applause/> I think Bill hit an important point here.....version numbers signal a lot to the user community about the compatability of the code, and the pain in migrating to various versions. To a developer, the name of 2.0.43++ isn't so imporant - call it 2.0.44, call it 2.1.0, call it 17.9 - it's the same code. To a user, the migration from 2.0.43 to 2.0.44 should be easy. >From 2.0.43 to 2.1 can be a little harder. It's much easier for end-users to understand releases if major functionality and/or API changes are coupled with minor version number bumps (instead of subversion bumps). From that perspective, changing the auth semantics (which have been pretty stable since at least early 1.3) 2.0.44 seems almost sneaky compared to changing them in 2.1.0. If minor version numbers are bumping weekly, that's not so good. If they are bumping quarterly or so as APIs change, that may well be healthier than carrying the 2.0 series on until the next major code reorganization. Version numbers are a marketing issue at least as much as a technology issue - here's an easy chance to give non-developers more insight into what is going on.
