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
--~--~---------~--~----~------------~-------~--~----~
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-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
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-releaseYes, 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 --~--~---------~--~----~------------~-------~--~----~ 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-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> ...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? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 11/5/07, Michael Koziarski <michael@koziarski.com> wrote:> > > ...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 --~--~---------~--~----~------------~-------~--~----~ 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-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> > 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 thatGiven 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 --~--~---------~--~----~------------~-------~--~----~ 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-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---