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

[Andrea Bolognani]

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:
> > I think this need to be considered very carefully.
> > 
> > I'm not overly familiar with the Python ecosystem but it would appear
> > that, despite PEP 440 not mandating this, many (most?) of the
> > packages uploaded to PyPi are using semantic versioning.
> 
>   
> https://packaging.python.org/guides/distributing-packages-using-setuptools/#choosing-a-versioning-scheme
> 
> Semver is the recommended approach, but they explicitly list date
> based versioning as a valid alternative
> 
>   "Semantic versioning is not a suitable choice for all projects, 
>    such as those with a regular time based release cadence and a 
>    deprecation process that provides warnings for a number of 
>    releases prior to removal of a feature."
> 
> That paragraph describes QEMU's scenario.

The section on date based versioning continues with

  A key advantage of date based versioning is that it is
  straightforward to tell how old the base feature set of a
  particular release is given just the version number.

  Version numbers for date based projects typically take the form of
  YEAR.MONTH (for example, 12.04, 15.10).

The problem with QEMU's version numbers is that, while they are date
based, they still *look* like semver, so it wouldn't be at all
unreasonable for the user to expect that they also *behave* like
semver.

This is not much of a problem when it comes to the main binary, but
it is certainly much more confusing when you start using the same
version number for a Python library.

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

-- 
Andrea Bolognani / Red Hat / Virtualization