Re: [Distutils] Bug in setuptools version parsing when appending '.dev'?
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.
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
participants (2)
-
Dave Peterson -
Phillip J. Eby