Re: about QEMU release schedule

Re: about QEMU release schedule

[Liu, Yi L]

>> On Dec 6, 2019, at 17:57, Peter Maydell <peter.maydell@linaro.org> wrote:
>> 
>> On Fri, 6 Dec 2019 at 04:00, Liu, Yi L <yi.l.liu@intel.com> wrote:
>> Hi Peter,
>> I’m wondering what’s the rule of QEMU version naming and release.
>> I noticed there is a v3.1.1.1 released after v4.1.0 was released.
> 
> Any reason for not just asking this on the public lists?

No, I should have cced mailing list, thus other people would learn it as well. 

>> Also, I’d like to query the release plan in 2020. What version would it
>> be in 2020-July?
> 
> For many years we've done major releases three times
> a year, in April, August and December (roughly).
> Starting from 4.0, we switched to a naming convention where
> the major number just increments once a year. So 2019's
> releases are 4.0, 4.1 and 4.2; 2020's will be 5.0, 5.1
> and 5.2, and so on.
> 
> Further releases on stable branches (eg 4.0.1, etc) are
> not handled by me -- they're done by Mike Roth. I don't
> know what the usual pattern is for those or how many
> branches back we do updates for.

Thanks a lot for the sharing. 

Regards,
Yi Liu

Re: about QEMU release schedule

[Michael Roth]

Quoting Liu, Yi L (2019-12-06 09:24:46)
> 
> >> On Dec 6, 2019, at 17:57, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> 
> >> On Fri, 6 Dec 2019 at 04:00, Liu, Yi L <yi.l.liu@intel.com> wrote:
> >> Hi Peter,
> >> I’m wondering what’s the rule of QEMU version naming and release.
> >> I noticed there is a v3.1.1.1 released after v4.1.0 was released.
> > 
> > Any reason for not just asking this on the public lists?
> 
> No, I should have cced mailing list, thus other people would learn it as well. 
> 
> >> Also, I’d like to query the release plan in 2020. What version would it
> >> be in 2020-July?
> > 
> > For many years we've done major releases three times
> > a year, in April, August and December (roughly).
> > Starting from 4.0, we switched to a naming convention where
> > the major number just increments once a year. So 2019's
> > releases are 4.0, 4.1 and 4.2; 2020's will be 5.0, 5.1
> > and 5.2, and so on.
> > 
> > Further releases on stable branches (eg 4.0.1, etc) are
> > not handled by me -- they're done by Mike Roth. I don't
> > know what the usual pattern is for those or how many
> > branches back we do updates for.
> 
> Thanks a lot for the sharing. 

Re-sending with qemu-devel included:

Generally 4.0.x is maintained until 4.1 releases, 4.1.x until 4.2,
etc. It's not a hard cut-off though, if a release is needed for
something significant like a CVE or regression a month or so past
that then a release might still be made. We just can't keep supporting
every branch forever, but if something is brought to my intention
that's not too far outside that window then I'll generally try to
work something out.

The safest bet though is to target fixes for a major release N,
tag/Cc: qemu-stable@nongnu, and it should get picked up for
a stable release of N-1 if applicable. Anything beyond that, let me
know.

3.1.1/3.1.1.1 were quite a bit later than usual due to delays on my
end and late-breaking CVEs; consider those exceptional cases.

There are more details on the process here:

  https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/devel/stable-process.rst;hb=HEAD

> 
> 
> Regards,
> Yi Liu