<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alexander Michael wrote:
<blockquote
cite="mid:525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Jul 30, 2008 at 8:05 PM, Dave Peterson <a class="moz-txt-link-rfc2396E" href="mailto:dpeterson@enthought.com"><dpeterson@enthought.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Am I missing something or is the following a bug whereby adding the '.dev'
tag is doing something weird?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">from pkg_resources import parse_requirement as pv
pv('1.0a1.dev') < pv('1.0a1')
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">True
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">pv('1.0a1') < pv('1.0')
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">True
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">pv('1.0a1.dev') < pv('1.0.dev')
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">False
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">pv('1.0a1') < pv('1.0.dev')
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">False
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">import setuptools
setuptools.__version__
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">'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'.
</pre>
</blockquote>
<pre wrap=""><!---->
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).
</pre>
</blockquote>
<br>
Actually, you can append the tag 'final' and it seems to work fine:<br>
<br>
>>> pv('3.0.final.dev') > pv(3.0b1')<br>
True<br>
<br>
I just hate to add the tag 'final' to a final release due to the extra
typing it causes people. It seems to me the community expectation is
to be able to do things like "easy_install Traits==3.0" rather than
"easy_install Traits==3.0.final"<br>
<br>
<br>
<blockquote
cite="mid:525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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).
</pre>
</blockquote>
<br>
The problem here is that we *released* Traits 3.0. It is no longer a
beta. But other projects that wanted to rely on it as soon as it was
in a stable beta put in a requirement of "Traits >=3.0b1".
Unfortunately, if developers check-out the tag of the release and do a
build, they get Traits with version "3.0.dev-rXXXXX' which setuptools
says doesn't satisfy "Traits >=3.0b1". They get the '.dev'
because we have historically not modified the source's setup.cfg when
tagging the release (we do NO changes between the last build/test cycle
and the tagging.)<br>
<br>
<br>
-- Dave<br>
<br>
</body>
</html>