[libvirt] Switch to a time based version number rule
Daniel P. Berrange
berrange at redhat.com
Mon Jun 13 16:58:58 UTC 2016
On Mon, Jun 13, 2016 at 06:57:01PM +0200, Andrea Bolognani wrote:
> On Mon, 2016-06-13 at 17:42 +0100, Daniel P. Berrange wrote:
> > 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
>
> 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.
Having a full year in there means more typing for everyone
and I think skipping version numbers would actually be
confusing, as it could people to think there was a missing
release
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the libvir-list
mailing list