A new release of your package: update the version, note the release date in the history.txt file, commit those changes, make a tag, upload to pypi if applicable, switch the version and history.txt back to development.
That really gets on your nerves if you have to do it more than once per day. So I made some zest software -internal scripts. Internal scripts ought to be released as small tools usable for everyone, right? So zest.releaser that does all the version/history/tag/release handling. By the nature of the tool, there are some assumptions on format, but they're common and well-documented on the pypi page.
We often have buildouts with multiple self-developed packages. I've written before about our generic strategy:
src/, now infrae.subversion puts them there (from
unstable.cfgif you've split your buildout "the zest way"). Core benefit: your
stable.cfgcan use the same mechanism to put tag checkouts in the same spot.
Looking up, and changing, the correct tags is what the second tool, zest.stabilizer does for you. Again, there are some assumptions here. The assumptions/requirements are more intruding than zest.releaser's, of course. See the pypi page for that.
needreleasecommand looks up all the src/ packages and returns their last svn log message. If that's "Back to dev" or so, you've apparently already made a proper release. If not, you'll have to check it.
stabilizecommand looks up the last (numerically) available tag and puts that into the
Combined, these two tools make it super-easy for us to do proper releases in a minimum of time. If you do them regularly, they become proper non-events. Eventful happenings during releases are bad :-)
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):