[libvirt] Switch to a time based version number rule

[Daniel P. Berrange]

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