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:07:27 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote:
> On Wed, May 02, 2018 at 09:02:00AM +0100, Daniel P. Berrangé wrote:
> > On Wed, May 02, 2018 at 09:44:03AM +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > > If we bump the major version each year anyway, why not go the whole 
> > > > > way
> > > > > and use 2018.1, 2018.2, ... (or even <year>.<month>)? The nice thing
> > > > > about that is that you can see at a glance when the release took 
> > > > > place.
> > > > 
> > > > ... or simply drop the first two digits and call them 18.1, 18.2, ...?
> > 
> > > We could also drop the major/minor scheme altogether (as they are
> > > meaningless anyway) and just go for YYMM, i.e. 1808 (for a august
> > > release).
> > 
> > I don't much like that - it'll lead to a wierd progression of numbers
> > where we'll be constantly the rationale re-explaining to people who
> > want to know why we've jumped from 1808 to 1902 to 1905 etc
> 
> 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

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]