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.