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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list