qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 03/15] python: add VERSION file


From: Daniel P . Berrangé
Subject: Re: [PATCH v2 03/15] python: add VERSION file
Date: Tue, 20 Oct 2020 10:06:23 +0100
User-agent: Mutt/1.14.6 (2020-07-11)

On Tue, Oct 20, 2020 at 10:52:14AM +0200, Andrea Bolognani wrote:
> On Mon, 2020-10-19 at 11:02 +0100, Daniel P. Berrangé wrote:
> > On Mon, Oct 19, 2020 at 11:45:09AM +0200, Andrea Bolognani wrote:
> > > With that in mind, I think it would be unwise for qemu.* not to do
> > > the same; in particular, using a version number that's not <1.0.0 for
> > > a package that is very much in flux will almost certainly break
> > > people's expectations, and is also not something that you can easily
> > > take back at a later time.
> > 
> > I don't think it is that big a deal, and there is clear benefit to
> > having the python code version match the QEMU version that it is
> > the companioon to.
> > 
> > Ultimately the versioning scheme just impacts on the version string
> > conditionals people list for their dependancies. Apps consuming QEMU
> > can handle any of the version schemes without much difference.
> 
> The problem comes from the expectations: a Python programmer, who is
> used to semver due to its prominence on PyPi, when deciding whether
> to move from qemu.core 4.2.0 to 5.0.0 might expect to need code
> changes to cope with API-breaking changes - where in fact there are
> none, and at the same time might expect upgrading to 5.2.0 from 5.0.0
> to be completely straightforward when in reality a feature their
> application depends on might have been removed after the usual
> deprecation period.

The QEMU python modules are not like other python modules though,
precisely because they are talking to QEMU. If we are shipping
QEMU python releases on the same schedule as QEMU, then we can
expect the normal ase to be updating both QEMU & Python together.
So regardless of versioning in the python code, the QMP code they
are talking to is liable to have removed deprecated features they
are using.  IMHO the upgrade issue is largely a problem of docs
and testing, semver is no magic bullet.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]