RFC: Switch to a date-based versioning scheme
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. Of course semver doesn't make sense for us, given our extremely strong backwards compatibility guarantees, and that's exactly why we've left it behind with 2.0.0; however, that's something that's not immediately obvious to someone who's not very involved with our development process, and regarless of our intentions libvirt version numbers *will* be mistakenly assumed to be semver-compliant on occasion. 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? [1] https://semver.org/ -- Andrea Bolognani / Red Hat / Virtualization
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 :|
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. IMO it would be better if our version numbers simply didn't look as much like semver in the first place, curbing any misunderstanding about this right away. If we really don't want to do YY.MM, can we follow the example of projects like systemd, GNOME and Debian, and use a single number? So libvirt 10 instead of 10.0.0 11 10.1.0 12 10.2.0 ... 19 10.9.0 20 10.10.0 21 11.0.0 If I haven't messed up my calculation, with this approach we'll be able to celebrate the release of libvirt 100 in January 2033 :) -- Andrea Bolognani / Red Hat / Virtualization
On Mon, Oct 30, 2023 at 04:31:38AM -0500, Andrea Bolognani wrote:
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.
This isn't a popularity contest. There are many 1000's of applications and libraries out there that have never used semver and never will. If people blindly assume the whole world is semver then they're going to be disappointed forever. If Rust/Go mandate semver that's fine - and indeed for libvirt-go we express an alternative semver scheme - but that doesn't mean every other ecosystem has to change its versioning approach 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 :|
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. Michal
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? -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Oct 31, 2023 at 04:20:24AM -0700, 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.
The problem here is "looks like semver" is nonsense. When you see a version number all you see is a sequence of numeric components, aka the syntax. Semver is one mechanism of assigning semantics to version numbers. You can't say that a number "looks like" semver, as the version string in isolation tells you nothing about semantics. Avoiding something that "looks like" semver is essentially stealing the pratically the entire version number space just for exclusive use by semver.
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 don't see this as a problem we need to fix.
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. 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 :|
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.
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.
Alright, I'm clearly the only one who thinks that this is something that could be improved upon, so I'll duly shut up now :) -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Oct 31, 2023 at 8:56 AM Andrea Bolognani <abologna@redhat.com> 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. -- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Nov 01, 2023 at 06:35:06AM -0400, Neal Gompa wrote:
On Tue, Oct 31, 2023 at 8:56 AM Andrea Bolognani <abologna@redhat.com> 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.
And that's fine because for elf libraries, the software release version is irrelevant. The ELF file itself has an embedded version that can and does evolve separately from the software release version, in order to expresss compatibility. A libvirt release contains more than just the libvirt.so library & we explicitly reserve the right to break compat for the libvirt-qemu.so and libvirt-lxc.so libraries, while keeping libvirt.so unchanged. 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 :|
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
participants (5)
-
Andrea Bolognani -
Daniel P. Berrangé -
Ján Tomko -
Michal Prívozník -
Neal Gompa