Forwarding this again to ruby-core as received a postmaster delivery failur=
e.

---------- Forwarded message ----------
From: Luis Lavena <luislavena / gmail.com>
Date: Sat, Oct 22, 2011 at 11:08 AM
Subject: Re: [ruby-core:40273] Re: Can rubygems save us from
"binary-compatibility hell"?
To: ruby-core / ruby-lang.org, "RubyGems Developers (ML)"
<rubygems-developers / rubyforge.org>


Hello,

Please see comments inline...

On Sat, Oct 22, 2011 at 5:21 AM, Eric Hodel <drbrain / segment7.net> wrote:
>
>> The other is a binary gem that includes a compiled extension
>> library. =A0TEENY release will be done about every year. =A0This
>> is not a technical issue, but do you think it is reasonable
>> to make gem developers release their binary gems when new
>> Ruby is released?
>
> I think it depends on the developer. =A0I can make a list of recent platf=
orm gems so we can consult the authors. =A0With the addition of the Develop=
er Kit for Windows rubyists it may not be as big a concern now as it has be=
en in the past. =A0Luis can comment better here.
>

Well, that depends on what are the dependencies of those gems. If the
gem just use C extension for speed and don't depend on external
libraries (e.g. RedCloth, rdiscount, hpricot) then is not an issue if
there is no binary gem for the newer version of Ruby.

But, this is a problem for more complex gems like EventMachine,
nokogiri and others that depend on externals (openssl, libxml2).

More than that, there is an existing problem with RubyGems that forced
us to create "fat-binary" gems which include binaries for 1.8.x and
1.9.x so gem can be installed properly.

Projects like rake-compiler made this task a bit more easy, yet still
requires gem author certain environment adjustments.

While 1.8.x usage has been reduced lately, it is still present.

With this ABI compatibility change it will require those gem authors
wanting to provide fat-binary gems for every single ABI version in the
same gem.

I've presented this issue before at rubygems developer list, April 2009:

http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html

>> And, is it possible to allow users to use, with a new Ruby, an old gem t=
hat does not support the new Ruby with a warning?
>
> This would require further adjustments to RubyGems, but I think it is pos=
sible. =A0Some of the adjustments are related to the stdlib gems proposal (=
coming soon).
>

Perhaps RubyGems' Specification will require to be extended to a list
of versions the gem is compatible with and not just one unique
version?

Those are my only concerns: gem authors overhead when packaging binary
gems and making more easy to gem users install them without falling
into the compile-your-own rabbit hole.

Thank you.
--
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=E9ry