qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering
Date: Thu, 3 May 2018 15:43:21 +0200
User-agent: NeoMutt/20180323

On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote:
> On 3 May 2018 at 10:07, Daniel P. Berrangé <address@hidden> 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).

If we don't want give them a meaning, how about:

  (d) just drop the minor and count up major each release (systemd style)?

My personal preference would be (a) or (b), because it is easy to see
when a version was released.  (b) looks more like a classic version
number, we would have 18.0, 18.1, ... instead of 18.04, 18.08, ...

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]