Hello, Please see comments inline...
On Sat, Oct 22, 2011 at 5:21 AM, Eric Hodel <drbr...@segment7.net> wrote: > >> The other is a binary gem that includes a compiled extension >> library. TEENY release will be done about every year. This >> 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. I can make a list of recent platform > gems so we can consult the authors. With the addition of the Developer Kit > for Windows rubyists it may not be as big a concern now as it has been in the > past. Luis 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 that >> does not support the new Ruby with a warning? > > This would require further adjustments to RubyGems, but I think it is > possible. Some 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éry _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
