[libvirt] Switch to a time based version number rule

[Daniel P. Berrange]

On Mon, Jun 13, 2016 at 06:36:50PM +0200, Andrea Bolognani wrote:
> On Mon, 2016-06-13 at 13:56 +0100, Daniel P. Berrange wrote:
> > 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
> 
> I don't like this. A widely used convention is to bump major
> when breaking backwards compatibility, minor when adding
> features in a backwards-compatible way, and micro when fixing
> bugs that don't alter the interface. Releasing a 2.0.0 would
> read, for many, as we had just broken API / ABI compatibility.

That convention isn't applicable for libvirt since we promise
to never break API / ABI, and we've already bumped major version
number in the past without anyone getting confused. . The libvirt
ELF so version number is explicitly separated and distinct from
the release version numbers, as due to our ABI promise we are
fixed at libvirt.so.0 forever.  So I don't see any compelling
reason to stick with major==1  forever in our release versions

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