Phillip J. Eby wrote:
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""').
We have that alias too, which is how we build releases but everyone else
defaults to a .dev-r1234 type of suffix on their version numbers.
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
This is pretty much our exact process too! Only difference are that we
do alpha and beta versions in the setup.py AND we svn tag the 0.4 and
0.5 versions. The problem I'm having is when someone gets those tagged
versions and does a build. Those builds don't satisfy dependencies that
the alpha and betas did. :-(
-- Dave
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
