Hi,
> libvirt suffered similar lack of clarity around when to bump major version
> number as opposed to minor version. To address this we recently adopted the
> rule[1] that major version number changes have no relation to features. The
> major number is simply incremented at the start of each calendar year.
I like the idea of time-based version numbering. Changing the plan for
2.9 still is probably a bad idea given we have a 2.9 machine type
already etc.
But we can start changing things afterwards. So we could start with 3.x
after 2.9, and bump the major for the first release each year
(libvirt-style). Or we could use the year as major number and jump
straight to 17.x (mesa-style).
> From the POV of libvirt, I don't think saying that .0 releases have
> incompatible changes is particularly useful in itself. What *is* useful
> is to have a clear rule around a deprecation cycle. ie, a rule that says
> a feature will be marked deprecated for 3 releases or 12 months, before it
> is permitted to be removed/changed. If that were followed, there is no
> need to batch up such changes in a .0 release IMHO.
Yes, it's probably a good idea to deprecate things first. When going
with the 12 months rule it could be useful to batch things and do a
yearly "spring cleaning" when the major is bumped.
We could also create new machine types for major versions only, to keep
the number somewhat under control. Not sure how well that would work in
practice. We'd probably need a ${type}-next machine type then (future
${type}-4 machine type, for development, incompatible changes allowed)
and make ${type}-3 the default machine type.
cheers,
Gerd
