On May 19, 3:35 pm, James Tucker <jftuc...@gmail.com> wrote: > On 19 May 2010, at 11:55, Luis Lavena wrote: > > Not at this time, and highly unlikely is going to happen, as that will > > require change in the Specification, indexing and fetching mechanisms, > > which if you read the above thread, will see not going to happen. > > This should be easier to move forward with since gemcutter, however, we have > to address backward compatibility, I think we've had enough major changes in > the last year that we should be careful with further major server side > changes that could introduce either further backward compatibility issues, > and/or increased support load for the team. Some of the old proposals could > be problematic in this manner, although I still like their final goals, ofc.
Actually, I think it is better that way. With RubyGems I am not even sure why it bothers to divide gem install by ruby version, i.e. /usr/ lib/ruby/gems/1.8/ vs. /usr/lib/ruby/gems/1.9/. That kind of division made sense for setup.rb b/c installs would literally clobber each other there, but that is no longer the case with gems. So why bother? My feeling it that it is better to strive for universal packages, than it is to slice and dice a new gem for every platform variation. Not only does it make packaging easier, but I think it can contribute to keeping the various implementations in sync. That aside, perhaps someone can explain to me the relationship between RUBY_PLATFORM, RUBY_ENGINE and gem platform? _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
