At 12:02 PM 8/4/2008 -0500, Dave Peterson wrote:
Phillip J. Eby wrote:
At 07:05 PM 7/30/2008 -0500, Dave Peterson 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'.
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.
This is what 'rc' tags are for, actually. You can put your version
in the source, and use the -b option to egg_info while doing builds
and testing to tack on an 'rc' tag, possibly with a subversion number as well.
Perhaps I'm missing something, but that doesn't seem like it scales
to a community -- not everyone is going to remember to use a '-b'
option when building and that is going to cause endless support problems.
Only the creator of a release uses that; the community should never
be building "release" versions.
We do put the following in our setup.cfg so that people don't
mistakenly build release versions when not intending to do so:
[egg_info]
tag_build = .dev
tag_svn_revision = 1
Are you staying the standard process for setuptools is to delete /
modify this when tagging a release in the repo?
I personally don't tag releases in the repository; a release is not a
tag. I have an alias called 'release' that maps to 'egg_info -Rdb
""', and I use it when issuing release builds.
However, there's nothing stopping you from creating a utility that
copies the trunk to a tag, checks out the tag, removes the options,
and checks in the tag, if that would be your preferred approach.
If not, how do you avoid the problem of someone building from a
source checkout and finding out that 3.0.dev-r1234 doesn't satisfy
the '>= 3.0b1' dependency spec?
I bump the version number in SVN immediately after making a release,
so that the trunk would be '3.1.dev-r1234', not '3.0dev'. If you're
using .dev tags in your egg-info setup, you should bump the version
in setup.py immediately *after* releasing, to avoid just this situation.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
