Which RubyGems version does ML ship with?

Here you go, my setup is vanilla Mountain Lion GM:

$ gem --version
1.3.6

I'm not sure if you want to consider ML bugs yet, but as the release is just a few days away and this is expected to be the final version, I figured you would be interested to know how Cocoapods behaves on that new platform.

Definitely, but I’ll have to install it first to do some proper debugging. Version 1.3.6 should be good, but in the meantime, could you update RubyGems and see if that fixes it?

sudo gem update --system

Installing RubyGem 1.8.24 fixes the problem, thanks!

Please note that JSONKit is the only package among the 25 pods our project uses that behaved this way. Other packages with a >= constraint but with more traditional version numbers installed the expected version.

My latest setup (which fixes the bug):

$ pod --version ; ruby --version ; gem --version ; gem list
0.8.0
ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]
1.8.24

*** LOCAL GEMS ***

activesupport (3.2.6)
addressable (2.2.8)
bundler (1.1.4)
cocoapods (0.8.0)
colored (1.2)
escape (0.0.4)
faraday (0.8.1)
faraday_middleware (0.8.8)
hashie (1.2.0)
i18n (0.6.0)
json (1.7.3)
multi_json (1.3.6)
multipart-post (1.1.5)
octokit (1.7.0)
open4 (1.3.0)
rake (0.9.2.2)
rubygems-update (1.8.24)
xcodeproj (0.2.3)

Damn, it’s a real shame Apple did not upgrade Ruby or RubyGems.

I think the fix for this issue was in RubyGems 1.4.0: Dependency “~>”s now respect lower-bound prerelease versions.

We’ll probably have to back port that to 1.3.6 by monkey-patching :(

(Btw, I have update the title to reflect the issue.)

So this issue would also impact a vanilla Lion install, right?

Indeed, so I will have to push out a fix for this ASAP.

Unfortunately trying to backport the fixes meant vendoring so much RubyGems code, that I decided to just have the user update their version. We now exit immediately with a helpful error message telling the user to update.