When VERSION is set to a development snapshot (micro >= 50), or a release
candidate (micro >= 90) we have an off-by-1 in determining deprecation
and deletion thresholds for versioned machine types. In such cases we need
to use the next major/minor version in threshold checks.
This adapts the deprecation macros to do "next version" prediction when
seeing a dev/rc version number.
This ensures users of release candidates get an accurate view of machines
that will be deprecated/deleted in the final release.
This requires hardcoding our current release policy of 3 releases per
year, with a major bump at the start of each year, and that dev/rc
versions have micro >= 50.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
include/hw/boards.h | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 74a8e96b2e..a6784fe984 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -650,11 +650,42 @@ struct MachineState {
" years old are subject to deletion after " \
stringify(MACHINE_VER_DELETION_MAJOR) " years"
-#define _MACHINE_VER_IS_EXPIRED_IMPL(cutoff, major, minor) \
+#define _MACHINE_VER_IS_CURRENT_EXPIRED(cutoff, major, minor) \
(((QEMU_VERSION_MAJOR - major) > cutoff) || \
(((QEMU_VERSION_MAJOR - major) == cutoff) && \
(QEMU_VERSION_MINOR - minor) >= 0))
+#define _MACHINE_VER_IS_NEXT_MINOR_EXPIRED(cutoff, major, minor) \
+ (((QEMU_VERSION_MAJOR - major) > cutoff) || \
+ (((QEMU_VERSION_MAJOR - major) == cutoff) && \
+ ((QEMU_VERSION_MINOR + 1) - minor) >= 0))
+
+#define _MACHINE_VER_IS_NEXT_MAJOR_EXPIRED(cutoff, major, minor) \
+ ((((QEMU_VERSION_MAJOR + 1) - major) > cutoff) || \
+ ((((QEMU_VERSION_MAJOR + 1) - major) == cutoff) && \
+ (0 - minor) >= 0))
+
+/*
+ * - The first check applies to formal releases
+ * - The second check applies to dev snapshots / release candidates
+ * where the next major version is the same.
+ * e.g. 9.0.50, 9.1.50, 9.0.90, 9.1.90
+ * - The third check applies to dev snapshots / release candidates
+ * where the next major version will change.
+ * e.g. 9.2.50, 9.2.90
+ *
+ * NB: this assumes we do 3 minor releases per year, before bumping major,
+ * and dev snapshots / release candidates are numbered with micro >= 50
+ * If this ever changes the logic below will need modifying....
+ */
+#define _MACHINE_VER_IS_EXPIRED_IMPL(cutoff, major, minor) \
+ ((QEMU_VERSION_MICRO < 50 && \
+ _MACHINE_VER_IS_CURRENT_EXPIRED(cutoff, major, minor)) || \
+ (QEMU_VERSION_MICRO >= 50 && QEMU_VERSION_MINOR < 2 && \
+ _MACHINE_VER_IS_NEXT_MINOR_EXPIRED(cutoff, major, minor)) || \
+ (QEMU_VERSION_MICRO >= 50 && QEMU_VERSION_MINOR == 2 && \
+ _MACHINE_VER_IS_NEXT_MAJOR_EXPIRED(cutoff, major, minor)))
+
#define _MACHINE_VER_IS_EXPIRED2(cutoff, major, minor) \
_MACHINE_VER_IS_EXPIRED_IMPL(cutoff, major, minor)
#define _MACHINE_VER_IS_EXPIRED3(cutoff, major, minor, micro) \
--
2.49.0On 06/05/2025 18.00, Daniel P. Berrangé wrote: > When VERSION is set to a development snapshot (micro >= 50), or a release > candidate (micro >= 90) we have an off-by-1 in determining deprecation > and deletion thresholds for versioned machine types. In such cases we need > to use the next major/minor version in threshold checks. > > This adapts the deprecation macros to do "next version" prediction when > seeing a dev/rc version number. > > This ensures users of release candidates get an accurate view of machines > that will be deprecated/deleted in the final release. > > This requires hardcoding our current release policy of 3 releases per > year, with a major bump at the start of each year, and that dev/rc > versions have micro >= 50. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > include/hw/boards.h | 33 ++++++++++++++++++++++++++++++++- > 1 file changed, 32 insertions(+), 1 deletion(-) FYI, this causes a failure in the CI now: https://gitlab.com/thuth/qemu/-/jobs/9965651507#L163 Looks like we have to remove the related subtest now? Thomas
On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote: > On 06/05/2025 18.00, Daniel P. Berrangé wrote: > > When VERSION is set to a development snapshot (micro >= 50), or a release > > candidate (micro >= 90) we have an off-by-1 in determining deprecation > > and deletion thresholds for versioned machine types. In such cases we need > > to use the next major/minor version in threshold checks. > > > > This adapts the deprecation macros to do "next version" prediction when > > seeing a dev/rc version number. > > > > This ensures users of release candidates get an accurate view of machines > > that will be deprecated/deleted in the final release. > > > > This requires hardcoding our current release policy of 3 releases per > > year, with a major bump at the start of each year, and that dev/rc > > versions have micro >= 50. > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > include/hw/boards.h | 33 ++++++++++++++++++++++++++++++++- > > 1 file changed, 32 insertions(+), 1 deletion(-) > > FYI, this causes a failure in the CI now: > > https://gitlab.com/thuth/qemu/-/jobs/9965651507#L163 > > Looks like we have to remove the related subtest now? Oh indeed yes. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 8/5/25 10:53, Daniel P. Berrangé wrote: > On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote: >> On 06/05/2025 18.00, Daniel P. Berrangé wrote: >>> When VERSION is set to a development snapshot (micro >= 50), or a release >>> candidate (micro >= 90) we have an off-by-1 in determining deprecation >>> and deletion thresholds for versioned machine types. In such cases we need >>> to use the next major/minor version in threshold checks. >>> >>> This adapts the deprecation macros to do "next version" prediction when >>> seeing a dev/rc version number. >>> >>> This ensures users of release candidates get an accurate view of machines >>> that will be deprecated/deleted in the final release. >>> >>> This requires hardcoding our current release policy of 3 releases per >>> year, with a major bump at the start of each year, and that dev/rc >>> versions have micro >= 50. >>> >>> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> >>> --- >>> include/hw/boards.h | 33 ++++++++++++++++++++++++++++++++- >>> 1 file changed, 32 insertions(+), 1 deletion(-) >> >> FYI, this causes a failure in the CI now: >> >> https://gitlab.com/thuth/qemu/-/jobs/9965651507#L163 Ah, just noticed the same error msg: qemu-system-x86_64: unsupported machine type: "pc-q35-4.1" >> >> Looks like we have to remove the related subtest now? Hmmm shouldn't we merge this series on top of up-to-4.1 machines removal?
On Thu, May 08, 2025 at 12:21:20PM +0200, Philippe Mathieu-Daudé wrote: > On 8/5/25 10:53, Daniel P. Berrangé wrote: > > On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote: > > > On 06/05/2025 18.00, Daniel P. Berrangé wrote: > > > > When VERSION is set to a development snapshot (micro >= 50), or a release > > > > candidate (micro >= 90) we have an off-by-1 in determining deprecation > > > > and deletion thresholds for versioned machine types. In such cases we need > > > > to use the next major/minor version in threshold checks. > > > > > > > > This adapts the deprecation macros to do "next version" prediction when > > > > seeing a dev/rc version number. > > > > > > > > This ensures users of release candidates get an accurate view of machines > > > > that will be deprecated/deleted in the final release. > > > > > > > > This requires hardcoding our current release policy of 3 releases per > > > > year, with a major bump at the start of each year, and that dev/rc > > > > versions have micro >= 50. > > > > > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > > > > --- > > > > include/hw/boards.h | 33 ++++++++++++++++++++++++++++++++- > > > > 1 file changed, 32 insertions(+), 1 deletion(-) > > > > > > FYI, this causes a failure in the CI now: > > > > > > https://gitlab.com/thuth/qemu/-/jobs/9965651507#L163 > > Ah, just noticed the same error msg: > > qemu-system-x86_64: unsupported machine type: "pc-q35-4.1" > > > > > > > Looks like we have to remove the related subtest now? > > Hmmm shouldn't we merge this series on top of up-to-4.1 machines > removal? There's no dependency on that series in general, just removal of the test case. We need to remove that test case regardless, because our machines will automatically remove registration of the machine type, regardless of whether the code is deleted. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 8/5/25 12:23, Daniel P. Berrangé wrote: > On Thu, May 08, 2025 at 12:21:20PM +0200, Philippe Mathieu-Daudé wrote: >> On 8/5/25 10:53, Daniel P. Berrangé wrote: >>> On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote: >>>> On 06/05/2025 18.00, Daniel P. Berrangé wrote: >>>>> When VERSION is set to a development snapshot (micro >= 50), or a release >>>>> candidate (micro >= 90) we have an off-by-1 in determining deprecation >>>>> and deletion thresholds for versioned machine types. In such cases we need >>>>> to use the next major/minor version in threshold checks. >>>>> >>>>> This adapts the deprecation macros to do "next version" prediction when >>>>> seeing a dev/rc version number. >>>>> >>>>> This ensures users of release candidates get an accurate view of machines >>>>> that will be deprecated/deleted in the final release. >>>>> >>>>> This requires hardcoding our current release policy of 3 releases per >>>>> year, with a major bump at the start of each year, and that dev/rc >>>>> versions have micro >= 50. >>>>> >>>>> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> >>>>> --- >>>>> include/hw/boards.h | 33 ++++++++++++++++++++++++++++++++- >>>>> 1 file changed, 32 insertions(+), 1 deletion(-) >>>> >>>> FYI, this causes a failure in the CI now: >>>> >>>> https://gitlab.com/thuth/qemu/-/jobs/9965651507#L163 >> >> Ah, just noticed the same error msg: >> >> qemu-system-x86_64: unsupported machine type: "pc-q35-4.1" >> >>>> >>>> Looks like we have to remove the related subtest now? >> >> Hmmm shouldn't we merge this series on top of up-to-4.1 machines >> removal? > > There's no dependency on that series in general, just removal of the > test case. We need to remove that test case regardless, because our > machines will automatically remove registration of the machine type, > regardless of whether the code is deleted. Great then :)
© 2016 - 2025 Red Hat, Inc.