Yes, this is indeed a bug. Depending on how you look at it, it's either
1. a bad specification in the rails 22.214.171.12443 gemspec which points to
the non-existent activesupport 126.96.36.19943, or
2. a failure to upload activesupport 188.8.131.5243.
The ROOT cause of this, however, is the rather strange
version-numbering scheme for edge rails gems. The approach of
appending the revision number to the current 'regular' version number
is less-than-optimal for a couple of reasons:
A.) The sequential ordering of gem versions results in different
release lines being mixed together. For example:
1. 184.108.40.20619 (2.0 trunk)
2. 1.2.5 (1.2 branch)
3. 220.127.116.1194 (2.0 trunk)
4. 1.2.4 (1.2 branch)
B.) Confusion which can result in incorrect dependencies being
specified (which happened in this case, with the mistake being made by
whoever packaged and released the gem)
A more sensible solution would be to give a real major or minor
version number to all trunk/edge releases. This might require a
little more planning for the Rails devs, but it would make life a lot
simpler. As long as you still kept the edge gems only on the
gems.rubyonrails.server and not rubyforge, this would work fine. Then
you would have sensibly-sorted versions like this:
1. 18.104.22.16819 (2.0)
2. 22.214.171.12449 (2.0)
3. 1.2.5 (1.2)
4. 1.2.4 (1.2)
...then, for the first "public" release, version it as 2.0.1, push it
to rubyforge, and all is well.
Then, there would be no confusion of which major/minor/tiny prefix
went with the associated edge revision prefix and the wierd mixing of
different releases branches when you sort versions. As long as the
devs can proactively decide what the next major release version will
This would also have the benefit of making it much easier to "float"
on the latest edge gem, using a RubyGems version spec with the
"pessemistic" operator like "~= 126.96.36.199"
I've opened this as  ().