[Rubygems-developers] The case of binary gems and Ruby versions.

Daniel Berger djberg96 at gmail.com
Thu Apr 16 19:53:31 EDT 2009

Eric Hodel 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
> Package a gem with both libraries inside, and add something to 
> require_paths for 1.8 vs 1.9

Could this be automated somehow? Can we dynamically set the linkage 
within a gem on Windows based on the version of Ruby that's running it?



More information about the Rubygems-developers mailing list