My PyPI Release Checklist

pypi-release-checklist.md

• Update HISTORY.md
• Commit the changes:

git add HISTORY.md
git commit -m "Changelog for upcoming release 0.1.1."

• Update version number (can also be minor or major)

bumpversion patch

• Install the package again for local development, but with the new version number:

python setup.py develop

• Run the tests:

tox

• Submit a pull request with the history and version number changes. Have it reviewed and merged.
• Release on PyPI by uploading both sdist and wheel:

python setup.py sdist upload
python setup.py bdist_wheel upload

• Test that it pip installs:

mktmpenv
pip install my_project
<try out my_project>
deactivate

• Push: git push
• Push tags: git push --tags
• Check the PyPI listing page to make sure that the README, release notes, and roadmap display properly. If not, copy and paste the RestructuredText into http://rst.ninjs.org/ to find out what broke the formatting.
• Edit the release on GitHub (e.g. https://github.com/audreyr/cookiecutter/releases). Paste the release notes into the release's release page, and come up with a title for the release.

@jpeyret

• https://python-packaging-user-guide.readthedocs.org/en/latest/distributing/ -> https://packaging.python.org/distributing/

This is an old gist, and I'm new to all of this. But isn't it odd to first commit your changes, then update version number in files and build the package, and then push the changes? Aren't you missing out on the version changes and the new build?

You can also use twine to securely upload to Pypi :twine upload dist/*

@BramVanroy no, because bumpversion creates another commit just for the version change. So in total you have one commit for the History changes, and one for the version bump.

Great list! Suggestion for an additional check: Run twine check dist/* after python setup.py sdist to run some additional checks (for example that the markdown/rst on pypi will render properly etc).