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 :|
