Thomas proposed a new deprecation and removal policy for versioned
machine types that would see them liable for deletion after 6 years:
https://lists.nongnu.org/archive/html/qemu-devel/2024-04/msg04683.html
This suggest was met with broad approval, however, I suggested that we
could take it further and actually mark them deprecated sooner, at the
3 year timeframe, and also fully automate the enablement of the runtime
deprecation warning without developer intervention on every release
cycle.
This series implements my suggestions.
The first patch introduces some helper macros and documents a standard
code pattern for defining versioned machine types across targets.
The next 6 patches convert existing targets with versioned machine
types (arm, s390x, ppc, m68k, i386) to use the new helper macros and
code patterns.
A further patch introduces some helper macros for automating the
handling of deprecation and deletion of versioned machine types.
Two more patches then enable the deprecation and deletion logic
across all versioned machines
Finally we do some cleanup and document the new policy.
........a tangent about VERSION file handling.......
One oddity here, is that during the development and release
candidate phases the automatic logic in this series has an off-by-1
error.
This is because when we, for example, add the "9.1" machine type
versions, the VERSION file is still reporting '9.0.50', and then
'9.0.9{1,2,3,4}'.
IOW, during development and in rc candidates, we fail to deprecate
and delete 1 machine type. We should already have deprecated the
6.1 machine types, but the most recently deprecated is 6.0.
This is pretty harmless since the final release does the right
thing.
I wonder, however, whether we would benefit from changing how we
update the VERSION file.
eg instead of re-using the micro digit to indicate a dev or rc
snapshot, represent those explicitly. eg "9.1.0-dev" and
"9.1.0-rc1", "9.1.0-rc2", etc in VERSION.
We don't use the full QEMU_VERSION in the code in all that many
places. It appears in some help messages for command line tools,
and in QMP query-version response, and in a few other misc places.
At a glance it appears all of those places would easily handle a
tagged version.
For release candidates in particular I think it would be saner
to show the user the actual version the release is about to become,
rather than the previous release's version. This would make the
reported version match the rc tarball naming too which would be
nice.
Anyway, this isn't a blocker for this machine type versioning
proposal, just a thought....
Changed in v2:
- Various docs improvements and minor fixes from original
review
- Rebased and resolved conflicts with Philippe's merged
series
Daniel P. Berrangé (14):
include/hw: add helpers for defining versioned machine types
hw/arm: convert 'virt' machine definitions to use new macros
hw/s390x: convert 'ccw' machine definitions to use new macros
hw/ppc: convert 'spapr' machine definitions to use new macros
hw/m68k: convert 'virt' machine definitions to use new macros
hw/i386: convert 'i440fx' machine definitions to use new macros
hw/i386: convert 'q35' machine definitions to use new macros
include/hw: add macros for deprecation & removal of versioned machines
include/hw: temporarily disable deletion of versioned machine types
hw: set deprecation info for all versioned machine types
hw: skip registration of outdated versioned machine types
hw/ppc: remove obsolete manual deprecation reason string of spapr
machines
hw/i386: remove obsolete manual deprecation reason string of i440fx
machines
docs: document special exception for machine type deprecation &
removal
docs/about/deprecated.rst | 13 ++
hw/arm/virt.c | 30 ++--
hw/i386/pc_piix.c | 220 ++++++++++++---------------
hw/i386/pc_q35.c | 215 +++++++++++---------------
hw/m68k/virt.c | 53 ++++---
hw/ppc/spapr.c | 96 ++++++------
hw/s390x/s390-virtio-ccw.c | 98 ++++++------
include/hw/boards.h | 298 +++++++++++++++++++++++++++++++++++++
include/hw/i386/pc.h | 28 ++++
9 files changed, 681 insertions(+), 370 deletions(-)
--
2.43.0