[libvirt] Switch to a time based version number rule

[John Ferlan]

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.

John
> 
> IOW, over the next 2 years we'll do the following releases off master:
> 
>  - Jul  1, 2016 - 2.0.0
>  - Aug  1, 2016 - 2.1.0
>  - Sep  1, 2016 - 2.2.0
>  - Oct  1, 2016 - 2.3.0
>  - Nov  1, 2016 - 2.4.0
>  - Dec  1, 2016 - 2.5.0
> 
>  - Jan 15, 2017 - 3.0.0
>  - Mar  1, 2017 - 3.1.0
>  - Apr  1, 2017 - 3.2.0
>  - May  1, 2017 - 3.3.0
>  - Jun  1, 2017 - 3.4.0
>  - Jul  1, 2017 - 3.5.0
>  - Aug  1, 2017 - 3.6.0
>  - Sep  1, 2017 - 3.7.0
>  - Oct  1, 2017 - 3.8.0
>  - Nov  1, 2017 - 3.9.0
>  - Dec  1, 2017 - 3.10.0
> 
>  - Jan 15, 2018 - 4.0.0
>  - Mar  1, 2018 - 4.1.0
>  - Apr  1, 2018 - 4.2.0
>  - ....
> 
> 
> The stable release branch naming would just use the first major + minor
> digit in its name.. eg the stable branch for 2.3.0 would use v2.3-maint
> and do stable releases 2.3.1, 2.3.2, 2.3.3, etc.
> 
> Regards,
> Daniel
>