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

[Daniel P . Berrangé]

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.010.1.0
>   24.04.010.2.0
>  ...
>   24.11.010.9.0
>   24.12.010.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 :|

RFC: Switch to a date-based versioning scheme

[Andrea Bolognani]

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.010.1.0
  24.04.010.2.0
 ...
  24.11.010.9.0
  24.12.010.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