[ruby-core:40918] Re: Fwd: Re: Can rubygems save us from "binary-compatibility hell"?

Hello,

Thank you all for discussing this proposal.
Sorry I have not followed all replies yet, but I will.
This is a reply to Eric and Luis.


2011/10/22 Eric Hodel <[e-mail]>:
>> Note that this is currently just my idea, not a decision at
>> all.  What do you think?
>
> I think your idea is possible and easy to implement.

Such confidence!



2011/10/22 Luis Lavena <[e-mail]>:
> But, this is a problem for more complex gems like EventMachine,
> nokogiri and others that depend on externals (openssl, libxml2).

Sorry I can't understand.  Why does it become more difficult if
it depends on external library?


> 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.

You mean "fat-binary" will become fatter to include binaries for
1.8, 1.9, 2.0.0, 2.0.1, ..., right?  Indeed it looks uncool, but
so matter in practice?  Aren't Eric planning to address this issue?


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

Slightly off topic, 1.8 will be dying when 2.0.0 is released.
(2.0.0 will be released at Feb. 2013, and 1.8 will be abandoned
at June 2013)  So I don't feel like caring about 1.8.


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

Agreed.


> 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.

Yes, in a sense, this proposal intends to move the overhead from
the core team to gem authors.  I wonder if the overhead is too
heavy or not.  I guess the 2.0.x will be released about once a year
(or lesser frequent).

-- 
Yusuke Endoh <[e-mail]>