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

Eric Hodel drbrain at segment7.net
Thu Apr 16 19:15:29 EDT 2009

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

I prefer the later, as it'll be easiest to implement even though it  
will increase the burden on the packager.

More information about the Rubygems-developers mailing list