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

Luis Lavena luislavena at gmail.com
Thu Apr 16 06:11:04 EDT 2009


Hey Guys,

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.

Regards,
-- 
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


More information about the Rubygems-developers mailing list