RFC: Switch to a date-based versioning scheme

[Andrea Bolognani]

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