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(a)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?