We create awesome Python libraries and applications
This document describes how releases are supposed to be handled. Small variations are of course useful depending on the kind of project.
Check hg status
make check if available
run pylint
test from clean checkout with all supported Python versions
update ez_setup.py if still there
Update version info in package/__init__.py and/or setup.py
Check setup.py metadata: long description, trove classifiers
Update release date/code name in CHANGES if there
hg commit
make clean if available
make docs if applicable
For every supported version:
python2.x setup.py release bdist_egg sdist upload
Check PyPI release page for obvious errors
hg tag
Make a maintenance branch if applicable
Update homepage (release info), regenerate docs (+printable!)
Add new version/milestone to tracker categories
Write announcement and send to mailing list/python-announce
Perhaps write blog post
Update version info, add new CHANGES entry for next version
hg commit
hg push
Check git status
make check if available
run pylint
test from clean checkout with all supported Python versions
update ez_setup.py if still there
Update version info in package/__init__.py and/or setup.py
Check setup.py metadata: long description, trove classifiers
Update release date/code name in CHANGES if there
git commit
make clean if available
make docs if applicable
For every supported version:
python2.x setup.py release bdist_egg sdist upload
Check PyPI release page for obvious errors
git tag
Update homepage (release info), regenerate docs (+printable!)
Add new version/milestone to tracker categories
Write announcement and send to mailing list/python-announce
Perhaps write blog post
Update version info, add new CHANGES entry for next version
git commit
git push origin
git push --tags origin