On Mon, Oct 19, 2020 at 11:45:09AM +0200, Andrea Bolognani wrote: > On Wed, 2020-10-14 at 10:29 -0400, John Snow wrote: > > Python infrastructure as it exists today is not capable reliably of > > single-sourcing a package version from a parent directory. The authors > > of pip are working to correct this, but as of today this is not possible > > to my knowledge. > > > > The problem is that when using pip to build and install a python > > package, it copies files over to a temporary directory and performs its > > build there. This loses access to any information in the parent > > directory, including git itself. > > > > Further, Python versions have a standard (PEP 440) that may or may not > > follow QEMU's versioning. In general, it does; but naturally QEMU does > > not follow PEP 440. To avoid any automatically-generated conflict, a > > manual version file is preferred. > > > > > > I am proposing: > > > > - Python core tooling synchronizes with the QEMU version directly > > (5.2.0, 5.1.1, 5.3.0, etc.) > > > > - In the event that a Python package needs to be updated independently > > of the QEMU version, a pre-release alpha version should be preferred, > > but *only* after inclusion to the qemu development or stable branches. > > > > e.g. 5.2.0a1, 5.2.0a2, and so on should be preferred prior to 5.2.0's > > release. > > > > - The Python core tooling makes absolutely no version compatibility > > checks or constraints. It *may* work with releases of QEMU from the > > past or future, but it is not required to. > > > > i.e., "qemu.core" will always remain in lock-step with QEMU. > > > > - We reserve the right to split out e.g. qemu.core.qmp to qemu.qmp > > and begin indepedently versioning such a package separately from the > > QEMU version it accompanies. > > 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. NB, historically we've made arbitrary changes to the python code since it was not considered public API. If we make it official public API, then we would actually need to start following our deprecation process for the python code too. > 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. 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 :|
