Automate releases to pypi and github releases.

[illume]

Pre release 'dev' and release candidate('rc') builds of pygame through pip and pypi.

• decide to only 'do a release' when things are tagged, not merged into master.

github release tasks to automate.

• appveyor Windows uploads wheels to github release (also creating draft release).
• Mac uploads wheels from travis to github release
• source build (.tar.gz) uploads to github release.
• manylinux wheels uploads to github release.

pypi tasks to automate.

• appveyor Windows uploads wheels to pypi
• Mac uploads wheels from travis to github release
• manylinux wheels uploads to pypi
• source build (.tar.gz) uploads to pypi

documentation tasks to automate.

• github release updates pygame website project release (done, but currently disabled because spammers)
• what's new should be in the documentation somehow. Currently release notes are written into github as markdown, and transferred to pygame website as html via github API. Little examples of new features are needed otherwise people find it very hard to use the new stuff.
• generate list of PRs and short description for each PR. Maybe a github script. Note, the PR titles should be edited for readability before this script is run.

---

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

[illume]

@takluyver if you have some minutes, it would good to get your feedback on if this seems reasonable. (or any other python packaging experts driving by)

[takluyver]

Sounds OK to me. The main thing is to make sure the version numbers clearly indicate prereleases so that users only get them if they specify --pre.

I don't know how easy it would be to automate uploads for all the different platforms. Currently I think we're uploading at least the Linux and Windows wheels manually.

[lordmauve]

I probably wouldn't do every release, just tag certain specific alphas or betas. Otherwise tying bug reports back to versions affected could be harder.

Other than that this sounds sensible.

[illume]

Some time ago I implemented something like this for pygameweb at pygame/pygameweb#52

Having something that 'releases dev versions to pypi for testing' in a python package somewhere would be nice, but I don't have time for that now. So I'm just going to hack it into the pygame tree.

[illume]

I added a task list to the issue description of things that still need to be automated. My aim is to try and automate one or two things every .dev release, and to do the dev releases more often.

[MyreMylar]

Perhaps the (newish) Github Actions can help automate some of this.

[MyreMylar]

@illume I assigned this to you since you seemed to be doing it steadily anyway.

[ankith26]

Is this TODO list upto date, I guess releases are automated by now, right?