On a Tuesday in 2023, Andrea Bolognani wrote:
On Tue, Oct 31, 2023 at 12:13:14PM +0100, Michal Prívozník wrote:On 10/26/23 15:48, 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 > With a bit of math we are there already. ${MAJOR}+14 and count months from 0 (like real programmers do).Except we skip a month so even that doesn't work ;)Jokes aside, version is just a meaningless number. Even more so with backports. That's why we try to avoid versioned checks in qemu caps as much as possible. Firefox I'm using is now at 119.something.something and what does that tell me? Nothing (except that mozilla entered this stupid race with chromium). People ought to stop looking for patterns where there aren't any.There's a fairly big difference between end-user applications and libraries. semver is aimed at APIs, so it only covers the latter. And since it's been adopted so widely, with ecosystems such as Rust and Go going as far as requiring its use, it's quite natural that developers who see a version number that looks like it's following semver will tend to assume that it does. Since libvirt doesn't follow semver, wouldn't it be better for everyone if its version numbers didn't look like they do? To prevent the misunderstanding from happening in the first place?
I think the real question here is: Why did they people designing semver pick libvirt's versioning patterns if they do not give them the same meaning? Jano
Attachment:
signature.asc
Description: PGP signature
