5 ms·

QEMU releases are calendar-based, every four months, so "7.0" just means "first release of 2022", not "we got lots of new and shiny stuff so we bumped the major

by pm215 5y ago

QEMU releases are calendar-based, every four months, so "7.0" just means "first release of 2022", not "we got lots of new and shiny stuff so we bumped the major version" :-) More generally, what goes on in QEMU these days is mostly continued progression of existing work rather than sudden new developments: it's an established project making incremental improvements and following along with updates to hardware and other standards.

johnny22 5y ago
If that's the case, I wish they'd adopt a year.month style version then! I guess i never thought about their versioning though.
- pm215 5y ago
  It was simpler to just move from "major.minor and we bump the major infrequently and semi-arbitrarily when the minor is big enough to feel unwieldy" to "bump major for first release of the year" rather than completely change the version number format.
  - mdaniel 5y ago
    Merely for your consideration, I believe it'd be possible to match both goals by setting next year's version to 2023.0.0 I also didn't know about the leading number being a yearly increment and would have thought 7.0.0 was a substantial change over 6.0.0; setting the number to 2023.0.0 makes that distinction a lot more obvious
jaclaz 5y ago
Hmmm. From the home page: https://www.qemu.org/ https://www.qemu.org/ Latest releases 7.0.0 Apr 19th 2022 6.2.0 Dec 14th 2021 6.1.1 Dec 23rd 2021 And the "full list of releases": https://download.qemu.org/ https://download.qemu.org/ is not any better, I think that starting from 2018 the number means (roughly) the year: 3=2018 (or also early 2019) 4=2019 5=2020 6=2021 7=2022 but I can see no evidence of a 4 month fixed interval release.
- bonzini 5y ago
  Well, x.y.0 releases are all done on April, October and December.
- pm215 5y ago
  As the person who tagged v7.0.0 yesterday, I do in fact know our release cadence :-) As bonzini says, .0.0 is April, .1.0 August and .2.0 December. The x.y.1 are stable-branch releases which happen slightly more irregularly.
  - jaclaz 5y ago
    I don't doubt you know that cadence :), but without the additional info you just provided with the x.y.0 and x.y.1 distinction it didn't seem accurate when compared to the actual dates of the releases. So, to clarify: x is year (counting from 2016=1) ? (OR first release of a year gets a major version bump) IF last digit is 0 then y is to be decoded as: 0=April 1=August 2=December OTHERWISE IF last digit is 1 the y may (or may not) be decoded as above.
    - pm215 5y ago
      Yes, except that if the last digit is not 0 then it only tells you "this is on the stable branch that started at the x.y.0 tag", and says nothing about year or month. Stable branch releases usually happen about 4 months after the .0, but there's no regular cadence to them, nor any rule about whether there is none, one, or more from any particular mainline release. (The entire release process for them is largely separate from the main releases.)

by pm215 5y ago

johnny22 5y ago

If that's the case, I wish they'd adopt a year.month style version then! I guess i never thought about their versioning though.

pm215 5y ago
It was simpler to just move from "major.minor and we bump the major infrequently and semi-arbitrarily when the minor is big enough to feel unwieldy" to "bump major for first release of the year" rather than completely change the version number format.
- mdaniel 5y ago
  Merely for your consideration, I believe it'd be possible to match both goals by setting next year's version to 2023.0.0 I also didn't know about the leading number being a yearly increment and would have thought 7.0.0 was a substantial change over 6.0.0; setting the number to 2023.0.0 makes that distinction a lot more obvious

jaclaz 5y ago

Hmmm. From the home page: https://www.qemu.org/ https://www.qemu.org/ Latest releases 7.0.0 Apr 19th 2022 6.2.0 Dec 14th 2021 6.1.1 Dec 23rd 2021 And the "full list of releases": https://download.qemu.org/ https://download.qemu.org/ is not any better, I think that starting from 2018 the number means (roughly) the year: 3=2018 (or also early 2019) 4=2019 5=2020 6=2021 7=2022 but I can see no evidence of a 4 month fixed interval release.

bonzini 5y ago
Well, x.y.0 releases are all done on April, October and December.
pm215 5y ago
As the person who tagged v7.0.0 yesterday, I do in fact know our release cadence :-) As bonzini says, .0.0 is April, .1.0 August and .2.0 December. The x.y.1 are stable-branch releases which happen slightly more irregularly.
- jaclaz 5y ago
  I don't doubt you know that cadence :), but without the additional info you just provided with the x.y.0 and x.y.1 distinction it didn't seem accurate when compared to the actual dates of the releases. So, to clarify: x is year (counting from 2016=1) ? (OR first release of a year gets a major version bump) IF last digit is 0 then y is to be decoded as: 0=April 1=August 2=December OTHERWISE IF last digit is 1 the y may (or may not) be decoded as above.
  - pm215 5y ago
    Yes, except that if the last digit is not 0 then it only tells you "this is on the stable branch that started at the x.y.0 tag", and says nothing about year or month. Stable branch releases usually happen about 4 months after the .0, but there's no regular cadence to them, nor any rule about whether there is none, one, or more from any particular mainline release. (The entire release process for them is largely separate from the main releases.)