Re: [libvirt] Switch to a time based version number rule

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