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é <berra...@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 :)
