Re: [libvirt] Switch to a time based version number rule
On Mon, Jun 13, 2016 at 07:09:49PM +0200, 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.
But misleading wrt stable releases that don't line up with the
months of the original releases.
> 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.
Well they don't go 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 which
is what we'd basically end up doing.
Anyway to get back on track, the key goal is getting away from the
version numbers whose meaning is associated with any features changes
in the release. In fact the goal is to go further and make sure that
each individual version number is *completely* meaningless, except in
how it relates to earlier version numbers. IOW, to avoid encoding
any semantic information in the version number, whether it is about
the feature changes, abi compatibility, or release date. The version
number is purely an arbitrary counter whose digits increment on each
release. Nothing more, nothing less.
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 :|