Bad propagation of 1.2.5 gems

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 (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
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"

I've opened this as [10074] ([1]).

Thanks,
--Chad

[1] http://dev.rubyonrails.org/ticket/10074

...then, for the first "public" release, version it as 2.0.1, push it
to rubyforge, and all is well.

That seems like a decent idea. However we could also use
1.9.9.svnrevision for the Release candidate and 2.0.0 for the public
release, right?

You could. But it seems more sensible to have the "MAJOR" and "MINOR"
portions be unchanged, and have the beta release versions be more
similar to what the final release will be. Is it really that
important that the "TINY" portion of the real release ends in zero?
If all releases from trunk at least incremented the "MINOR", it
shouldn't matter...

-- Chad

> That seems like a decent idea. However we could also use
> 1.9.9.svnrevision for the Release candidate and 2.0.0 for the public
> release, right?

You could. But it seems more sensible to have the "MAJOR" and "MINOR"
portions be unchanged, and have the beta release versions be more
similar to what the final release will be. Is it really that

Given that David's announcement refers to the beta gems as a "2.0
preview release", the 2.0 version numbering for those gems would seem
consistent. I'd also suggest that using the beta gems means I'm
'closer' philosphically speaking to Rails 2.x than 1.x. 1.2.5.xxxx is
particularly heinous (as compared with 1.9.9) as the code is much
'further away' from 1.2.5 than the build incremenent would suggest.

Just my 2c

Alan