On Thu, Apr 16, 2009 at 8:15 PM, Eric Hodel <drbr...@segment7.net> wrote: > On Apr 16, 2009, at 03:11, Luis Lavena wrote: >> >> Been investing a lot of time in Ruby 1.9 as I move forward for updated >> RubyInstaller (One-Click) for both 1.8.6 and 1.9.x branches. >> >> Because of that, I've started to realize, even more and more, that >> distributing binary gems between versions is set to failure. >> >> Let me explain my logic with a simple example. >> >> My gem contains a extension, which I compile, cross-compile and >> package for 'i386-mswin32' (x86-mswin32) using my stock Ruby 1.8.6 >> installation. I can also compile for the new RubyInstaller platform >> (mingw32) using the same approach. >> >> At the time I upload that to rubyforge, I upload the following files: >> >> my-gem-1.0.gem >> my-gem-1.0-x86-mswin32-60.gem >> my-gem-1.0-x86-mingw32.gem >> >> At this point, everything is good. >> >> Since the last 2 gems listed there are binary gems, those will be >> linking with msvcrt-ruby18.dll, which is the runtime library for Ruby >> on Windows (both MinGW and VC6). No problem so far. >> >> You wonder, where is the problem then? >> >> These gem where built for 1.8, so installing those in 1.9 will not >> fail unless I specify require_ruby_version (which is something >> rake-compiler now does). >> >> Now, the real problem becomes when I want to provide binaries for BOTH >> ruby version, since RubyGems, besides the required_ruby_version don't >> provide a mechanism to distinguish 1.8 from 1.9 gems, I end with the >> exact same gem names, with the exact same versions and platforms, thus >> overwriting previous versions. >> >> Someone suggested me that release 1.0.0 for Ruby 1.8 and 1.1.0 for >> Ruby 1.9, but that is misleading. >> >> I think we reached the point where RubyGems roadmap needs to start >> considering these cases to provide a more mature solution for us. > > I see two solutions: > > Package two separate gems with an indicator in the name for 1.8 vs 1.9 >
The problem is that indicating the version of ruby in the gem will not make the installation easy. > Package a gem with both libraries inside, and add something to require_paths > for 1.8 vs 1.9 > > I prefer the later, as it'll be easiest to implement even though it will > increase the burden on the packager. > It will end being a huge problem. What about adding officially support for gem-name-version-RUBY_VER-PLATFORM.gem -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
