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/
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
