Description

(calling this a "defect" because it resulted in confusion and an incorrectly-spec'd gem being uploaded. Change it to an enhancement if desired)

From rails-core mailing list, 11/4/07, subject "Re: [Rails-core] Bad propagation of 1.2.5 gems":

On 11/4/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:

It has come to my attention that errors with gem propagation reported by users on the official blog in mid-October [1][2] seem to persist. If you do "gem upgrade activesupport", version "1.4.4.7843" is installed, but rails gem 1.2.5.7843 requires activesupport 1.4.3.7843. The installation of Rails 1.2.5 fails with the following error: ERROR: While executing gem ... (Gem::GemNotFoundException) Could not find activesupport (= 1.4.3.7843 ) in any repository Also, doing "gem install rails -v 1.2.5" doesn't seem to install necessary dependencies. One is only able to install Rails from gems.rubyonrails.org as source: gem install -y rails --source http://gems.rubyonrails.org/ The "rails-1.2.5.7919" gem is then installed with correct dependencies. Does anyone know what caused these oddities with dependencies and incomplete propagation of gems? Thanks, - Mislav [1] http://weblog.rubyonrails.org/2007/10/12/rails-1-2-5-maintenance-release [2] http://weblog.rubyonrails.org/2007/9/30/rails-2-0-0-preview-release

Yes, this is indeed a bug. Depending on how you look at it, it's either

1. a bad specification in the rails 1.2.5.7843 gemspec which points to the non-existent activesupport 1.4.3.7843, or

2. a failure to upload activesupport 1.4.3.7843.

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. 1.2.5.7919 (2.0 trunk)
2. 1.2.5 (1.2 branch)
3. 1.2.4.7794 (2.0 trunk)
4. 1.2.4 (1.2 branch)
5. etc.

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. 2.0.0.7919 (2.0)
2. 2.0.0.7749
3. 1.2.5
4. 1.2.4

...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 be.

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 "~= 2.0.0.0"

Thanks, --Chad