Pre release pygame builds through pypi and pip.

(If there's any python packaging experts reading this, please comment if this doesn't seem reasonable. https://github.com/pygame/pygame/issues/409 You will get 42 internet points, and a cookie if you ever visit Berlin).

We want to be able to more widely test pre release builds, to avoid bugs and try things out on different OS/hardware combinations. This is the plan on how it will be done for pygame.

---

Pre release 'dev' and release candidate('rc') builds of pygame through pip and pypi.
  • every merge into master releases a dev build. 1.9.4.dev1+git.77.facebeef123
  • every release candidate tagged releases an rc build. 1.9.4.rc1

How to install pre release builds.

Pip pre-release documentation
`pip install pygame --pre`
Requiring a specific development build is possible according to the documentation.
`pip install pygame==1.9.4.dev1`

Version naming.

From packaging guide pre release versioning:
    zero or more dev releases (denoted with a “.devN” suffix)
    zero or more alpha releases (denoted with a “.aN” suffix)
    zero or more beta releases (denoted with a “.bN” suffix)
    zero or more release candidates (denoted with a “.rcN” suffix)
  • Dev versions will be named like this: 1.9.4.dev1+git.77.facebeef123 (version+local_version). With the dev1 becoming dev2, dev3. git describe can be used to get this info.
  • pygame.version.rev should have the git hash https://www.pygame.org/docs/ref/pygame.html#pygame.version.rev
  • Uploading wheels currently only happens when a tag happens. (eg, 1.9.3). Dev builds would instead need to happen when something is merged into master.
  • release candidates can be done with a tag. 1.9.4.rc1 will be release candidate 1.

git describe, for getting commits since last release.

Can be used to get the number of commits since the last release.
git describe --tags
1.9.3-124-g2d842abc
Using this we can grab the info we need to build the pypi-happy version strings.
Note, it needs to use --tags if we don't have annotated tags. (which we should use going forwards).

Dev builds to test pypi instead?

No.
  • piwheels don't download from testpypi, so we need to release to pypi to get these.
  • Also, the packaging guide doesn't talk about doing this. (it's just used for testing, and the DB is wiped occasionally).
  • Will pypi be cluttered with lots of dev releases? 3-20 per month (* 30 files)? I don't think this is a problem. There's nothing in the packaging guide to say don't do this.
  • people may have a need to rely on a specific dev version (especially since pygame is released infrequently), and testpypi gets wiped.

Comments

Popular posts from this blog

Is PostgreSQL good enough?

pygame on pypy usable

Experiments with new low latency PyPy garbage collector in a thread.