Phillip J. Eby wrote:
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.
Right, and that's the exact problem! They're grabbing the source via svn checkout from the release tag and doing their own build which ends up getting labeled as '3.0.dev-r1234' (which seems to be exactly the right thing to say to me -- it is an svn build of the 3.0 release) but this does not satisfy dependencies that are in other projects that were put out requiring "Traits >= 3.0b1". Sure I can tell people not to do that when they say it doesn't work, but I think it should work because the pattern works everywhere else (see below.)
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.
Great to hear about what you do, but we frequently have to support customers who need minor updates and having a tag that makes it easy to branch from, or re-create, a release is a very useful thing. We have to many developers who need to restart at a release point to be able to track the code state at release points using any other method we've seen.
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.
Hmm, and I thought I was clear saying that this is exactly what I do not want to do. :-) Ideally, we don't want to modify tags in anyway. Like you pointed out above, I don't want people accidentally building 'release' versions except the project maintainers.
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.
We DO do that. That doesn't solve the problem I'm talking about though. Let me try one more time.... There exist people who prefer to build from source they've gotten from the svn repo. These people don't want to worry about bugs in the trunk / development version so they go grab the source from the latest release tag. They then do a "setup.py bdist_egg" to build an egg that they plan to distribute within their company, work group, what have you as part of their shared project where they defined dependencies as ">=3.0b1" While the latest tagged version is 3.0b1, 3.0b2, 3.0c1, 3.0c2, etc. this process works great as all of those are correctly newer or equal to 3.0b1 even when .dev tags are appended to the version number. BUT, as soon as we tag and release the final 3.0 release, it breaks because 3.0.dev < 3.0b1. It will work fine again when we tag and release 3.1<anything> or 4.0<anything>. It is only the final release of 3.0 that exhibits this problem. This seems like a bug. -- Dave