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 (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.ru
byonrails.org/ticket/10074
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
|