<feed xmlns='http://www.w3.org/2005/Atom'>
<title>qemu/python/VERSION, branch master</title>
<subtitle>QEMU development tree</subtitle>
<id>https://git.zx2c4.com/qemu/atom/python/VERSION?h=master</id>
<link rel='self' href='https://git.zx2c4.com/qemu/atom/python/VERSION?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/'/>
<updated>2021-06-01T20:21:21Z</updated>
<entry>
<title>python: add VERSION file</title>
<updated>2021-06-01T20:21:21Z</updated>
<author>
<name>John Snow</name>
<email>jsnow@redhat.com</email>
</author>
<published>2021-05-27T21:16:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/qemu/commit/?id=3afc32906f7bffd8e09b7d247d60b55c49665bd3'/>
<id>urn:sha1:3afc32906f7bffd8e09b7d247d60b55c49665bd3</id>
<content type='text'>
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.

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 tooling follows the QEMU version, indirectly, but with a major
  version of 0 to indicate that the API is not expected to be
  stable. This would mean version 0.5.2.0, 0.5.1.1, 0.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. 0.5.2.0a1, 0.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.machine" will, for now, remain in lock-step with QEMU.

- We reserve the right to split the qemu package into independently
  versioned subpackages at a later date. This might allow for us to
  begin versioning QMP independently from QEMU at a later date, if
  we so choose.

Implement this versioning scheme by adding a VERSION file and setting it
to 0.6.0.0a1.

Signed-off-by: John Snow &lt;jsnow@redhat.com&gt;
Reviewed-by: Cleber Rosa &lt;crosa@redhat.com&gt;
Message-id: 20210527211715.394144-12-jsnow@redhat.com
Signed-off-by: John Snow &lt;jsnow@redhat.com&gt;
</content>
</entry>
</feed>
