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

[Cornelia Huck]

On Thu, 3 May 2018 10:07:27 +0100
Daniel P. Berrangé <address@hidden> wrote:

> 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

FWIW, both YY.MM and YYYY.MM look fine to me.