Re: RFC: Switch to a date-based versioning scheme
On Thu, Oct 26, 2023 at 06:48:28AM -0700, Andrea Bolognani wrote:
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.
I don't think that is the case. Any version number you ever
see can plausibly be a semver version when seen without any
context. The only way that confusion goes away is if we were
to actually use semver, or if people stop blindly assuming
every project uses semver. I don't think this is a reason
to change what we're doing.
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?
My thoughts on calver are unchanged since it was previously
suggested this
https://listman.redhat.com/archives/libvir-list/2016-June/131961.html
https://listman.redhat.com/archives/libvir-list/2016-June/131958.html
Our version numbers are explicitly just a counter that ticks
over on a defined schedule and semantic meaning should not be
attached to any single release number.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|