zest.releaser, zest.stabilizer¶

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:

• Split up the buildout . Works brilliantly once you get used to it. It really helps keep your development/production setups coordinated and neat.
• Use infrae.subversion for development packages . Normally you'd put them as svn:externals in src/, now infrae.subversion puts them there (from unstable.cfg if you've split your buildout "the zest way"). Core benefit: your stable.cfg can 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.

• The needrelease command 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.
• The stabilize command looks up the last (numerically) available tag and puts that into the stable.cfg.

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 :-)