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

[Kevin Wolf <kwolf@redhat.com>]

Am 04.05.2018 um 15:53 hat Thomas Huth geschrieben:
> On 04.05.2018 15:20, Kevin Wolf wrote:
> > 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.
> 
> ... and numbered machine types ...
> That's a very good point indeed, Kevin. We really should *not* do (a).
> And since we're currently doing releases in December, which could slip
> to January of the next year, I think we also should not do (b). This
> will only cause confusion and wrong expectations otherwise. So if we
> decide to bump the major release each year, (c) sounds like the best
> option to me (and if we slip such a release from December to January, it
> should be ok to keep the old major number).

Yes, I guess (c) could still work.

> >> 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.
> 
> Well, the version numbers will increase pretty fast this way. We should
> not be afraid of having QEMU 4711 one day...

Indeed, we'd get there in only 1569 years if we keep our current release
frequency until then.

More seriously, if you want to keep major and minor, and prefer them
both to stay low as long as possible, the ..., 3.9, 4.0, ... model is
probably what gets you closest to that.

On the other hand, I don't think it would be horrible if in about twenty
years we ended up at the 59.0 that Firefox has today.

> > It feels like the minimal change to fix our existing versioning scheme.
> > 
> > Or in fact:
> > 
> >     (e) What's the problem with 2.42, really?
> 
> People tend to mix up 2.42 with 2.4.2 ... and sometimes you get bad
> sorting in directory listings, when e.g. qemu-2.10.0-... shows up before
> qemu-2.2.0-... etc.

Good points, though I see them more as minor annoyances.

Anyway, it's a general point about double-digit minor versions and
another reason why (a) isn't a good idea if you plan to make releases
between October and December.

> > I agree that a constant "2." prefix isn't really useful, but it probably
> > doesn't really hurt either.
> 
> So let's do it the (old) Java / Sun way and simply drop the major number
> and continue counting with the minor number? Hmmm, no, never mind.

Would be essentially the same as I suggested, except starting with 13.0
instead of 3.0.

Kevin