[libvirt] Switch to a time based version number rule

Cole Robinson crobinso at redhat.com
Mon Jun 13 17:33:22 UTC 2016


On 06/13/2016 01:09 PM, Andrea Bolognani wrote:
> On Mon, 2016-06-13 at 17:58 +0100, Daniel P. Berrange wrote:
>>> 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.
>>  
>> Having a full year in there means more typing for everyone
> 
> A bit, yeah. On the other hand, I think it would make it even
> clearer that the release schedule is entirely time-based.
> 
>> and I think skipping version numbers would actually be
>> confusing, as it could people to think there was a missing
>> release
> 
> Think Ubuntu - they always have a six month gap between
> releases, but I've yet to hear anyone complain about that.

Honestly when I started reading Dan's initial mail I figured that's what he
was going to propose and gets my ACK. It has the handy feature that at a
glance even non-libvirt devs can tell exactly how old their libvirt version
is, not counting stable distro backport frankenstein monster versions. And it
should avoid any user confusion about whether bumping the major version means
we are breaking API compat, or if it's based on some fancy new feature, etc.

- Cole




More information about the libvir-list mailing list