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