Op 16-01-11 14:32, Alan Franzoni schreef:
I have played a bit with zest.releaser, and while it seems interesting I'm not sure about some things, e.g.:
I'd like to test my project *before* committing any version change or tagging anything. I'd like to pass a "candidate changeset" for a release; if all tests on such release succeed, I'd then like to tag the current changeset, upload everything to pypi, upgrade setup.py (or version.txt) with the next development version. zest.releaser offers setup.py entrypoint hooks, but maybe a buildout hook (run another part) would work better?
I would say just run the tests manually first (possibly as simple as running bin/test if you have a good buildout configuration) and then use the fullrelease command from zest.releaser. If you are afraid that changing the version string and updating the changelog/history file might possibly break the tests you could first run the prerelease command to set the version and history, then run the tests, then run the release command to tag and push to pypi or somewhere else, then the postrelease command to update the version and changelog of your current branch/trunk checkout to a development version.
Also, version.txt looks better than embedding the version in setup.py,
For the record, having a version.txt is a convention from years ago when Zope/Plone products needed it, because python packages with a setup.py were not widely used within Zope at that time, possibly because they had not been invented yet. :-)
but I'd like to follow even more a convention-over-configuration thing; I'd like release branches to be named something like
release_1.2 release_1.3
and I'd really like to pull version numbers from the branch name and latest revision from the tag info - nor version.txt neither setup.py should be committed at any time - that's often an issue because when working with multiple branches, the forward merge of version changes often produces merge errors that must be corrected manually. Saving version info in metadata like branch names or tags is a better solution, I think.
When you upload your package to pypi.python.org setup.py needs to know what version it is. In other words: you need some way of having 'python setup.py --version' come up with the correct version. Yes, merging can produce conflicts, but if version conflicts in a changelog and a setup.py are your worst merge problems then you can count yourself blessed. :-)
I'll try playing a bit with the zest.releaser source by the way, If I can reach a good result I'll let you know.
Cool. I get the feeling you are trying to solve a problem that I don't have or that I do not consider a problem though, so don't get your hopes up too high that changes are accepted for a release. But the code is in the Plone collective, so feel free to make a branch there: https://svn.plone.org/svn/collective/zest.releaser/trunk Getting write access to the Plone collective should not be too difficult. Short instructions are here: http://dev.plone.org/collective Cheers, -- Maurits van Rees Programmer at Zest Software http://zestsoftware.nl Personal website http://maurits.vanrees.org/