Re: [Qemu-devel] release retrospective, next release timing, numbering

[Kevin Wolf <kwolf@redhat.com>]

Am 03.05.2018 um 15:43 hat Gerd Hoffmann geschrieben:
> On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote:
> > On 3 May 2018 at 10:07, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote:
> > >> I don't see an issue with time-based numbering schemes.  Ubuntu made it
> > >> popular and other projects (like DPDK) are doing the same thing now.
> > >>
> > >> The convention is YY.MM though, not YYMM.
> > >
> > > It feels like we've got quite a strong backing for time based versioning
> > > amongst people replying here. I'd be happy with YY.MM
> > 
> > I'm not hugely in favour mostly because I don't much like
> > changing version numbering formats -- does it really gain
> > us anything? But I guess it's a bit of a bikeshed-colour question.
> 
> Well, major/minor numbers don't mean anything.  So I think it makes
> sense to give them a meaning, and given we do time-based releases it
> surely makes sense to use a time-based scheme.  Major indicating the
> year is the obvious and common choice here.  Various variants are in
> use:
> 
>   (a) major equals year, minor equals month (ubuntu style).
>   (b) major equals year, minor counts up (mesa style).
>   (c) major is bumped each year, but doesn't equal year (libvirt style).

I generally don't like time-based versioning schemes too much, but I
guess the only real objection I can think of is what happens when a
release slips? Either the version number wouldn't match the actual
release date, which doesn't look too good, or it's unpredictable during
the development cycle and we'd have to get used to fixing up things like
the "Since:" specification in the QAPI schema immediately before a
release.

But if I had to choose between these options, I think I'd go for (b) or
(c).

> If we don't want give them a meaning, how about:
> 
>   (d) just drop the minor and count up major each release (systemd style)?

I'm not sure what the exact systemd model is, but as we came to the
conclusion that there is no semantic difference between major and minor
version number for QEMU, I'd just merge them.

This would result in 3.0 for the next release, 3.1 etc. would be stable
releases, and the December release would be 4.0.

It feels like the minimal change to fix our existing versioning scheme.

Or in fact:

    (e) What's the problem with 2.42, really?

I agree that a constant "2." prefix isn't really useful, but it probably
doesn't really hurt either.

Kevin