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

[Thomas Huth]

On 04.05.2018 15:20, Kevin Wolf wrote:
> Am 03.05.2018 um 15:43 hat Gerd Hoffmann geschrieben:
>> 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).
> 
> I generally don't like time-based versioning schemes too much, but I
> guess the only real objection I can think of is what happens when a
> release slips? Either the version number wouldn't match the actual
> release date, which doesn't look too good, or it's unpredictable during
> the development cycle and we'd have to get used to fixing up things like
> the "Since:" specification in the QAPI schema immediately before a
> release.

... and numbered machine types ...
That's a very good point indeed, Kevin. We really should *not* do (a).
And since we're currently doing releases in December, which could slip
to January of the next year, I think we also should not do (b). This
will only cause confusion and wrong expectations otherwise. So if we
decide to bump the major release each year, (c) sounds like the best
option to me (and if we slip such a release from December to January, it
should be ok to keep the old major number).

>> If we don't want give them a meaning, how about:
>>
>>   (d) just drop the minor and count up major each release (systemd style)?
> 
> I'm not sure what the exact systemd model is, but as we came to the
> conclusion that there is no semantic difference between major and minor
> version number for QEMU, I'd just merge them.
> 
> This would result in 3.0 for the next release, 3.1 etc. would be stable
> releases, and the December release would be 4.0.

Well, the version numbers will increase pretty fast this way. We should
not be afraid of having QEMU 4711 one day...

> It feels like the minimal change to fix our existing versioning scheme.
> 
> Or in fact:
> 
>     (e) What's the problem with 2.42, really?

People tend to mix up 2.42 with 2.4.2 ... and sometimes you get bad
sorting in directory listings, when e.g. qemu-2.10.0-... shows up before
qemu-2.2.0-... etc.

> I agree that a constant "2." prefix isn't really useful, but it probably
> doesn't really hurt either.

So let's do it the (old) Java / Sun way and simply drop the major number
and continue counting with the minor number? Hmmm, no, never mind.

 Thomas