[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Huth
Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering
Date: Mon, 7 May 2018 07:33:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 04.05.2018 19:30, Richard Henderson wrote:
> On 05/04/2018 06:20 AM, Kevin Wolf wrote:
>> 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.
>> It feels like the minimal change to fix our existing versioning scheme.
> This is very similar to what GCC started to use at version 5.
>     https://gcc.gnu.org/develop.html#num_scheme
> I do think it makes sense to drop minor versions, leaving only major +
> patchlevel (which then appears to be minor version).

We're currently also using the patch level for marking developing
version (x.y.50) and release candidates (x.y.9r) ... we should also
think of a way how we want to map that to a new numbering scheme. If we
do it the GCC way, I guess the x.0 release will be the development
"versions"? But the release candidates? Do we still need a third number
for doing those (3.0.1 = rc1, 3.0.2 = rc2, ...)?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]