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

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?

systemd is in a similar position as us, where they can't really break compatibility because too much stuff is built on top, so they just use an ever-increasing version number. Simple and effective. Why can't we do the same?