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.

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?

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.

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).

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.

On Tue, Oct 31, 2023 at 04:20:24AM -0700, Andrea Bolognani wrote: > 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? Note systemd is not strictly single digit - their stable releases have an extra digit.

Our current version number scheme works fine. If people want to blindly assume semantics that don't exist & are documented to not exists directly on our download page, that's not something for us to fix.

On Tue, Oct 31, 2023 at 8:56 AM Andrea Bolognani <abologna(a)redhat.com&gt; wrote: > > On Tue, Oct 31, 2023 at 11:58:01AM +0000, Daniel P. Berrangé wrote: > > On Tue, Oct 31, 2023 at 04:20:24AM -0700, Andrea Bolognani wrote: > > > 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? > > > > Note systemd is not strictly single digit - their stable releases have > > an extra digit. > > And we could do the same. > I will also point out that systemd switched to an integer specifically so they could break everything all the time. The libsystemd library is not intended to be considered stable.