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: Daniel P . Berrangé
Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering
Date: Thu, 3 May 2018 10:31:03 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

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.

You mean the change from 3 to 2 digits ?   We would presumably need to
stick a zero on the end of it anyway. eg  18.04.0 indicates 2018, May
initial release. Then 18.04.1 indicates the first stable branch release,
etc.

Or if you mean you don't like the jump from 2.x to 18.x, we could just
follow a time based version scheme, but just bumping major digit once
a year as I first suggested in this thread ?

Both are effectively saying the same thing - we're changing versions
based on time, not features. So it is largely a matter of whether you
want the actual date visible or not.

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



reply via email to

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