zest.releaser, zest.stabilizerΒΆ

Tags: zestsoftware, plone, buildout, zestreleaser

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

(Old imported comments)
"They don't do the same job" by reinout on 2009-02-17 22:39:54
collective.releaser creates a whole different structure than zest's internal conventions call for. And both tools are for releasing eggs: we also want to tag our buildouts (and buildouts aren't eggs). And at the time the tools started, a private pypi didn't yet seem feasible. We split our buildouts in unstable/stable.cfg and want to update the stable one automatically.

And just updating the setup.py version isn't enough: version.txt is also (often) there. As are version numbers in the HISTORY.txt. That's the beauty of zest.releaser. Note that calling "python setup.py mdist" or so would be easy to support/add once we start to use collective.dist.

I know there are also still other tools apart from collective.releaser and collective.dist. Every one of them has a number of assumptions or internal policies hard-coded into them. I personally think that zest.stabilizer won't be used that much because it is REALLY intrusive in project structure (just like collective.releaser's template). Zest.releaser is way smaller in scope and seems real handy for lots of people.

I look forward to using collective.dist in combination with Rocky Burt's cluereleasemanager (http://pypi.python.org/pypi/ClueReleaseManager), btw :-)
"Import this!" by http://www.openidfrance.fr/encolpe on 2009-02-17 15:11:06
Hello,
why didn't you contribute to collective.releaser and collective.dist instead of create a new tool?
blog comments powered by Disqus
 
vanrees.org logo

About me

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.

Weblog feeds

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