[Distutils] Bug in setuptools version parsing when appending '.dev'?

[Dave Peterson]

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