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?

Regards,

Dan
_______________________________________________
Rubygems-developers mailing list
http://rubyforge.org/projects/rubygems
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers

Reply via email to