[libvirt] Switch to a time based version number rule

Currently libvirt uses a 3 digit version number, except when it uses a 4 digit version number. We have the following rules - major - no one has any clue about when we should bump this - minor - bump this when some "significant"[*] features appear - micro - bump this on each new release - extra - bump this for stable branch releases [*] for a definition of "significant" that no one knows Now consider our actual requirements - A number that increments on each monthly release - A number that can be incremented for stable branch releases Ok, the micro + extra digits deal with our two actual requirements, so one may ask what is the point of the major + minor digits ? In 11 years of libvirt development we've only bumped the major digit once, and we didn't have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitray. We just look at what features are around and randomly decide if any feel "big enough" to justify a minor digit bump. Way back in the early days of libvirt, we had exactly this kind of mess when deciding /when/ to actually make releases. Sometimes we'd release after a month, sometimes after 3 months, completely arbitrarily based on whether the chances felt "big enough" to justify a release. Feature based release schedules are insanity and so we wised up and adopted the time base release schedule where we release monthly (except over xmas/new year period). I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule. So what I'm suggesting is that we adopt the following rule - major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases Rather than wait until next January to adopt this rule, I'd suggest we pretend that it is January now, and thus switch our next version number to be 2.0.0, and jump to 3.0.0 in January 2017. IOW, over the next 2 years we'll do the following releases off master: - Jul 1, 2016 - 2.0.0 - Aug 1, 2016 - 2.1.0 - Sep 1, 2016 - 2.2.0 - Oct 1, 2016 - 2.3.0 - Nov 1, 2016 - 2.4.0 - Dec 1, 2016 - 2.5.0 - Jan 15, 2017 - 3.0.0 - Mar 1, 2017 - 3.1.0 - Apr 1, 2017 - 3.2.0 - May 1, 2017 - 3.3.0 - Jun 1, 2017 - 3.4.0 - Jul 1, 2017 - 3.5.0 - Aug 1, 2017 - 3.6.0 - Sep 1, 2017 - 3.7.0 - Oct 1, 2017 - 3.8.0 - Nov 1, 2017 - 3.9.0 - Dec 1, 2017 - 3.10.0 - Jan 15, 2018 - 4.0.0 - Mar 1, 2018 - 4.1.0 - Apr 1, 2018 - 4.2.0 - .... The stable release branch naming would just use the first major + minor digit in its name.. eg the stable branch for 2.3.0 would use v2.3-maint and do stable releases 2.3.1, 2.3.2, 2.3.3, etc. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|