Re: RFC: Switch to a date-based versioning scheme

On Thu, Oct 26, 2023 at 03:15:06PM +0100, Daniel P. Berrangé wrote: > 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. Humans are fairly decent at pattern recognition :) If something looks like a date, they are likely to interpret it as one. Among the projects that use date-based version numbers in a similar way to the one I proposed, in addition to Ubuntu which was already mentioned, we have edk2 and virt-firmware. > > 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 See, I knew we had discussed this already ;) > 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. > 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. Our intentions are very clear and well documented, but the problem is that we have zero control over other people's brains. Like it or not, semver is extremely popular, so people will see a version number that looks like it could conceivably be compliant with semver and assume that it is. We can point them to the relevant documentation if they mention this in a discussion that we're part of, but that only catches a tiny number of cases.