[libvirt] Switch to a time based version number rule

[Andrea Bolognani]

On Mon, 2016-06-13 at 17:42 +0100, Daniel P. Berrange wrote:
> 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

Fair enough. I still think people will be confused, but I
guess once we start bumping the major version number once
a year they'll get around to it.

If we really want to go time-based, why don't we keep it
really straightforward and predictable and do

  July 2016     -> 2016.7.0
  August 2016   -> 2016.8.0
  ...
  January 2017  -> 2017.1.0
  February 2017 -> 2017.2.0

If we'll happen to skip a month for whatever reason, we
can simply skip the corresponding minor number.

I guess we could omit the leading "20" and still be safe
for 80 more years. But not until libvirt's 100 years
anniversary, so I'd advise against it ;)

-- 
Andrea Bolognani
Software Engineer - Virtualization Team