On Mon, Jun 13, 2016 at 11:12:34AM -0400, John Ferlan wrote: > > > On 06/13/2016 08:56 AM, Daniel P. Berrange wrote: > > Currently libvirt uses a 3 digit version number, except when it uses > > a 4 digit version number. We have the following rules > > > > - major - no one has any clue about when we should bump this > > - minor - bump this when some "significant"[*] features appear > > - micro - bump this on each new release > > - extra - bump this for stable branch releases > > > > [*] for a definition of "significant" that no one knows > > > > Now consider our actual requirements > > > > - A number that increments on each monthly release > > - A number that can be incremented for stable branch releases > > > > Ok, the micro + extra digits deal with our two actual requirements, so > > one may ask what is the point of the major + minor digits ? > > > > In 11 years of libvirt development we've only bumped the major digit > > once, and we didn't have any real reason why we chose to the bump the > > major digit, instead of continuing to bump the minor digit. It just > > felt like we ought to have a 1.0 release after 7+ years. Our decisions > > about when to bump the minor digit have not been that much less arbitray. > > We just look at what features are around and randomly decide if any feel > > "big enough" to justify a minor digit bump. > > > > For "some" major release changes have other implications. Perhaps ABI or > RPC compatibility (or some other inter-operability concern). It'd be > "hard" to add some feature in say February that would historically > require the "need" for a major version bump and be forced to wait until > the following January to get that feature in. Or conversely keep track > that version M.1 or M.2 introduced some incompatibility. I have no hard > examples, just trying to consider history of other projects I've been > involved in. Since libvirt has promised never to break API/ABI, that rule doesn't apply to use, which is one of the factors why we've never had any decision about when to bump the major version. > Then there's the migration issue - would we need come up with thoughts > and policy around how to handle what can migrate to something else (or > how many versions back we'd "restore" some saved object/domain). BTW: > This version stuff becomes more complicated for downstream releases that > can have longer cycles between minor releases. Consider RHEL ~6 month > cycles - that means perhaps RHEL 7.4 and 7.6 could use drastically > different libvirt version numbers (which hopefully wouldn't have some > other incompatible change). WRT migration the only version number that is relevant at the QEMU machine type version numbers. The libvirt version number is never used for any functional logic decisions in our code. At most apps use the version number to decide when libvirt APIs appear, and that's not impacted by this suggested change. > Beyond that for certain enterprise corporations, using a "Major.0" is > not allowed because "historically" in the industry a major.0 release > comes with issues and has "compatibility implications". For one OS I > worked on in the past, we specifically chose to make a release "7.1" > instead of "7.0" for that very reason! We did create a 7.0 release, but > it was *purely* an advanced development and limited release (highly > controlled). For that release we had to be compatible with a 5.n release > as well (there was also a couple of 6.n releases). Again the mindset > being Major version number change implies major changes. Yeah, these are all the kind of insane reasons marketing people come up with for changing version numbers on products. In reality users are not so dumb as to be fooled by this kind of thing, and as an independant project I don't think we need care about this kind of thing anyway :-) > > Way back in the early days of libvirt, we had exactly this kind of > > mess when deciding /when/ to actually make releases. Sometimes we'd > > release after a month, sometimes after 3 months, completely arbitrarily > > based on whether the chances felt "big enough" to justify a release. > > > > Feature based release schedules are insanity and so we wised up and > > adopted the time base release schedule where we release monthly (except > > over xmas/new year period). > > > > > > 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 > > > > > > Rather than wait until next January to adopt this rule, I'd suggest we > > pretend that it is January now, and thus switch our next version number > > to be 2.0.0, and jump to 3.0.0 in January 2017. > > Not against being avant garde with respect to our numbering (after all > it's generally just a number). > > If we were to go this way, then I believe we should just start with the > July release being "2.5.0". That way we don't have to "think harder" > down the road. Yeah, we could do that. Although I illustrated it below, I didn't mean to imply that July would always be the N.5.0 release - that's just what happens if we do the long cycle for Jan/Feb. The slight variation would be to always use the month number as the minor version digit. I didn't want todo that though, since I think it would be confusing when we skip a digit due to not releasing in Feb. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list