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 :|
