Release Management with PyPI and GitHub
Wed 25 January 2023 by George DornI'm a core maintainer of Django-Tastypie, the oldest REST framework for Django. It predates Django-Rest-Framework and comes from the very earliest days of Class-Based Views, from when they were still very controversial. It's still in use by a lot of developers and companies, though these days the primary development efforts are in keeping it up-to-date with Django releases and bugfixing. It's still in Beta for some legacy reasons, but it's exceptionally mature.
This post is about a task I do roughly once a year, and forget how to do correctly every time: cut a new release. Because release management is not part of my day job and because I only do it once or twice a year, I always get something wrong.
The Right Process (for tastypie)
1. Bump the version number in tastypie.VERSION
TastyPie's version is written in one and only one place in the code: tastypie.VERSION. Every other mention of the version in code imports from that, to keep things from getting out of sync.
2. Update the Release Notes
The release notes are included in the docs. Every new release gets a new notes file, which must also be linked from the release_notes/index.rst page.
Tracking everything that has changed since the last release is a difficult but necessary step. In a perfect world, you'd be tracking changes as they are made, but this is hard enough for a single-developer project much less a community-maintained project. Instead, GitHub provides some tools for this on the Releases page. By default, this page shows the last release and, crucially, a link to show all commits made to master since this release. I try to keep this to the broad strokes, keeping the nitty-gritty details confined to our Backwards-Incompatible Changes file.
3. Release to PyPI
Make sure everything is ready to go before this step. It's not possible to change a release once published to PyPI.
Every time I do this, the toolchain has changed. Most recently, the preferred tool has changed to Twine which was relatively painless (if arcane):
$ pip install twine
$ python setup.py sdist
$ twine upload dist/*
You can provide authentication for twine in a configuration file, but given the recent NPM credential debacle it is probably a good idea to avoid putting your PyPI password in any cleartext file.
4. Create a Github Release / Tag
"Releasing" a Python library on GitHub is a bit of an anachronism; most users will be deploying from PyPI. But it is a simple process (just create a new Draft Release from the Releases page, pointing at either master or a release tag.) and worth it for the rollup diffs and commit log alone. But also, bafflingly, some linux distros still build TastyPie as a package, and they rely on github tags/releases to know when to build a new package.
Go to the releases page to draft a new release, picking the same commit that was published to PyPI to create a tag and name the release similarly.
Detecting Incomplete or Missing Migrations with Django and CircleCI
Update (2017-06-15): Django 1.10 added --check and deprecated --exit. This makes the logic far more easy to follow. Just run this instead:
python manage.py makemigration --dry-run --no-input --check
And the same command will work in CircleCI (or your favorite CI service.)
Original, deprecated:
It's pretty easy to ...
read moreUsing Tastypie Inside Django
Make use of a Tastypie's API from within Django
Tastypie is an excellent way to generate a REST API with minimal coding. But often it exists as a separate means of accessing your data, with its own implementation of your business logic, while your views also implement business logic ...
Legacy BooleanField in Django
A legacy BooleanField supporting all kinds of antiquated ways of storing boolean values.
Django's inspectdb is pretty good at providing models that will at least read and write from your legacy database. But to get real power out of the ORM, you may need to provide some custom mapping ...
Using Django Auth with a legacy app
One strategy for integrating a legacy python application with Django.
At work, we're planning to switch to Django. Rather than doing a complete feature freeze for six months while we rewrite the site in Django, the decision has been made to run two codebases and migrate features to Django ...
Django vs SQAlchemy (vs PyDO) Speed Tests
Speed tests for SQLAlchemy vs Django vs PyDO
At work, we're preparing to move away from a 6-year-old homebrew web framework to Django. In the process, I figured I'd do some speed tests of the old ORM (PyDO, version one, last updated in 2004 and with an author ...