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

[Thomas Huth]

On 03.05.2018 15:43, Gerd Hoffmann wrote:
> 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, ...

I'd really would like to avoid variant (a) ... otherwise people will
confuse 18.1.1 and 18.11 (aka. 18.11.0) again...

 Thomas