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 > > 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 :|
