RFC: Switch to a date-based versioning scheme

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