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

[Thomas Huth]

On 03.05.2018 11:31, Daniel P. Berrangé 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.
> 
> 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.

If we're going to a year-based numbering, I think we should do it the
"libvirt" way and simply increment the current number by one each year,
instead of jumping directly to 18. So in case this numbering scheme does
not work out as we expected, we can easier revert back to another
numbering scheme, without looking completely stupid due to the big
number gap and without having to explain later why QEMU version 19 is
*not* released in the year 2019.

 Thomas