Re: [PATCH 00/14] hw: define and enforce a standard lifecycle for versioned machines

[Daniel P . Berrangé]

On Fri, May 03, 2024 at 01:14:27PM +0100, Peter Maydell wrote:
> On Wed, 1 May 2024 at 19:28, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > 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.
> 
> I think the theory behind the VERSION file is that we want
> to be able to express the version:
>  * purely numerically
>  * in a strictly ascending order
> 
> We expose the assumption of numeric versions in places like
> QMP's query-version command, which reports it as a set of ints.

Right, we have:

#     -> { "execute": "query-version" }
#     <- {
#           "return":{
#              "qemu":{
#                 "major":0,
#                 "minor":11,
#                 "micro":5
#              },
#              "package":""
#           }
#        }


We could add an extra field to it thus:


#     -> { "execute": "query-version" }
#     <- {
#           "return":{
#              "qemu":{
#                 "major":0,
#                 "minor":11,
#                 "micro":5,
#                 "tag": "rc2"
#              },
#              "package":""
#           }
#        }

arguably we are still in strictly ascending order for the
numeric part, we merely didn't bump the numeric part of
the value at rc releases.

> I think there's probably scope for making the "human friendly"
> version string be surfaced instead of the strictly-numeric
> one in more places, but I worry that breaking the "always
> numeric and ascending" rule might have subtle breakage for
> us or for downstream uses...

Downstream I see no issues. There are already many projects which
use a '-dev' or '-rcNN' suffix for tarballs of unreleased versions,
and distros have guidelines on how they deal with this.

In fact downstream already deals with it for QEMU, because they will
typically set packaging versioning based on the version as seen in
the tarball name, not the different version seen in the VERSION file
(and thus QMP).

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