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

[Alexander Michael]

On Wed, Jul 30, 2008 at 8:05 PM, Dave Peterson <dpeterson at enthought.com> wrote:
> Am I missing something or is the following a bug whereby adding the '.dev'
> tag is doing something weird?
>
>>>> from pkg_resources import parse_requirement as pv
>>>> pv('1.0a1.dev') < pv('1.0a1')
> True
>>>> pv('1.0a1') < pv('1.0')
> True
>>>> pv('1.0a1.dev') < pv('1.0.dev')
> False
>>>> pv('1.0a1') < pv('1.0.dev')
> False
>>>> import setuptools
>>>> setuptools.__version__
> '0.6c8'
>
> This is mainly causing us problems when projects try to track alpha and beta
> level bumps in dependencies, such as when project Foo requires project Bar
> version 3.0b1 via a requirement like 'Bar >= 3.0b1' (which means we don't
> want the development prereleases of Bar's first beta release, but anything
> after that should be okay.)   But then when we actually want to release Bar
> 3.0 and change the version number to just '3.0', suddenly installs fail
> while we try to run the last set of tests because '3.0.dev' is older than
> '3.0b1'.

This looks wrong to me too. One would think that the development
version 3 (final) would be newer than any 3.beta version. But both dev
and b are pre-release tags with dev being explicitly mapped to '@' in
the parsed version so that it is treated as younger than beta:

In [2]: v('3.0.dev')
Out[2]: ('00000003', '*@', '*final')

In [3]: v('3.0b1')
Out[3]: ('00000003', '*b', '00000001', '*final')

The rationale is probably that dev releases represent "early"
development releases, while beta releases are closer to the final
release than dev releases. What I think is missing is a way of saying
(silently) that this a dev of the final, and that final is newer than
beta (and especially a dev of a beta).

> If it is not a bug, how do you handle situations where you want to run that
> last round of testing prior to tagging and building releases?  I'd rather do
> that AFTER making all source changes, and not have to change the version
> number after the testing.

To work with what we have now, I think you need to set the trunk
version to 3b2.dev (the next in-development version). And then when
you're ready for the final version of 3, bump your working copy of the
trunk to 3 (final) and do a test build with the .dev dropped (perhaps
from the command-line with python setup.py egg_info -RDb "" sdist
bdist_egg) in a virtualenv or similar sandbox where you can easily
manually wipe site-packages in case you need to iterate. Once that's
good, commit, branch and tag, release, and then immediately commit the
trunk version to 3.1.dev (3.0.1 bug-fix releases will be prepared in
the branch).