At 01:41 PM 8/4/2008 -0400, Alexander Michael wrote:
Again, attempting to offer up practical solutions. Edit the
setup.cfg's to drop the dev option in the release branches and update
the trunk to the next version (i.e. 3.1.dev-rXXXXX)? That way,
checkouts of the release branches will be 3.0-rXXXXX (a post release
of 3) and the trunk will be a post of a pre-release that is newer than
anything else in the repository. Just a thought...
This is basically what I do, except I don't bother having release
branches or tags, and instead of editing the setup.cfg, I just use my
"release" alias (which maps to 'egg_info -RDb""').
So, when I did two back-to-back releases of BytecodeAssembler today
(due to finding a bug after the first release), my command sequence was:
# start: version in setup.py is 0.4, release on Pypi is 0.3
# do development of version 0.4 w/periodic checkins
setup.py wikiup # upload wiki pages
setup.py release sdist bdist_egg upload
# ... edit version number from 0.4 to 0.5 and check in
# ... find bug, fix it, check it in
setup.py wikiup # upload wiki pages
setup.py release sdist bdist_egg upload
# ... edit version number from 0.5 to 0.6 and check in
# end: version in setup.py is 0.6, release on Pypi is 0.5
Of course, a more robust procedure would probably be to use x.1
versions (e.g. 0.4.1 instead of 0.5), and then bump to the next
non-bugfix version number when development begins on the next
release. If you have release branches, then I guess you'd do the
bugfix bump on the branch, and a non-bugfix increment on the trunk.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
