On Mon, 2016-06-13 at 17:42 +0100, Daniel P. Berrange 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
On Mon, Jun 13, 2016 at 06:36:50PM +0200, Andrea Bolognani wrote: 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