Since we're just a few months away from the 10.0.0 release, I thought
it would be a good time to bring up this idea.
Can we move to date-based version numbers? I suggest having
libvirt 24.01.0 instead of 10.0.0
24.03.0 10.1.0
24.04.0 10.2.0
...
24.11.0 10.9.0
24.12.0 10.10.0
The big advantage is that, once version numbers are obviously
date-based, any expectation of them being interpreted according to
semver[1] are immediately gone.
Of course semver doesn't make sense for us, given our extremely
strong backwards compatibility guarantees, and that's exactly why
we've left it behind with 2.0.0; however, that's something that's not
immediately obvious to someone who's not very involved with our
development process, and regarless of our intentions libvirt version
numbers *will* be mistakenly assumed to be semver-compliant on
occasion.
People are quite used to date-based version numbers thanks to Ubuntu
having used them for almost two decades, so I don't think anyone is
going to be confused by the move. And since our release schedule is
already date-based, having the versioning scheme match that just
makes perfect sense IMO.
Up until now, one could have argued in favor of the current
versioning scheme because of the single-digit major version
component, but that's going away next year regardless, which makes
this the perfect time to raise the topic :)
Thoughts?
[1] https://semver.org/
--
Andrea Bolognani / Red Hat / Virtualization
