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

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.

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).

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.

> 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.