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. We should rather switch to bumping minor each release and keeping micro for stable branch releases. The only drawback I see is that the minor version would eventually become comically large, eg. we'll be at 1.60 in five years and we'll reach 1.100.0 by 2026. Not too big a deal IMHO. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list