Hi Bob, On 6 Aug 2010, at 22:30, Bob Friesenhahn wrote: > On Fri, 6 Aug 2010, Gary V. Vaughan wrote: >>> >>> OTOH, since I hope to have more larger changes in the future, I'm not >>> sure we really want another major number bump already. >> >> That's only a minor bump, according to major.minor.micro: >> >> major bump => substantial rewrite >> minor bump => new features, new code and new bugs >> micro bump => regressions and bugs fixed >> >> This is the scheme I believe most people recognize, and that suggests >> to me that 2.4.0 would be the next logical release number? > > You do make a good point. It is better to advance the minor number (rather > than continually increase the micro number) if significant new features have > been added. However, the objectives should be met (e.g. really able to build > adequately with MSVC) before we bump to 2.4. This should not discourage > including 99% of the necessary updates in another 2.2 release.
Nonetheless I still think that users should have some confidence that releases get more stable as micro increases. Rolling a ton of new code into a micro bump violates that idea. In this case I should either release a 2.2.12b alpha while we wait for the new MSVC code to be "adequate" for 2.4.0, or else make a retroactive 2.2 maintenance branch at v2.2.10 in git, and back- merge fix changesets only from trunk to make stable 2.2.12 while waiting for an appropriate time to roll 2.4.0 from master. IMHO 2.4.0 from master at the end of the month (assuming no known show-stoppers at that time) is a good and proper way to inform users that there's some new code (minor+=2), and that it's not at all mature (micro=0). 2.2.12, on the other hand, misinforms users that this is a stable release with nothing important altered (major.minor unchanged), and they really should upgrade to pick up the last round of bug fixes (micro+=2). Another viable compromise might be to call the next release 2.3.0? Cheers, -- Gary V. Vaughan (g...@gnu.org)
