Hello, rubygems developers --

I'd like to ask some questions about rubygems and Ruby's ABI
compatibility.


Currently, the core team tries to ensure ABI compatibility in
the same Ruby series.  This means an extension library file that
is compiled with 1.9.1 can be loaded successfully with 1.9.2.

However, it is sometimes frustrating for the core team to find
an ABI-compatible way to fix some problems. [ruby-core:28281]
[ruby-core:27945]
It is also unfortunate to postpone or give up some new features
or improvements because they break ABI compatibility.
[ruby-core:39847]
In addition, the definition of ABI compatibility is ambiguous
a little.  I think "ABI compatibility" is actually ensured, but
some don't. [ruby-core:36108]


So, it would be good to discard ABI compatibility in 2.0.
Each version of Ruby (including TEENY) should have their own
library path, such as:

  /usr/lib/ruby/2.0.0/
  /usr/lib/ruby/2.0.1/
  /usr/lib/ruby/2.0.2/
  etc.

In this policy, all the users have to re-install libraries that
they are using whenever ruby is upgraded.  It's a pain.  But
recently, many libraries are gems.


So I'd like to ask a question to rubygems developers; is it
technically possible to automatically re-install all gems from
old Ruby installation to new one when Ruby is upgraded (or
during "make install")?

I have two concerns.  One is a user-custom gem that a user
created and not published in rubygems.org.  Is there a custom
gem or its source necessarily remained?

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

And isn't there another concern I missed?


Note that this is currently just my idea, not a decision at
all.  What do you think?

-- 
Yusuke Endoh <mame / tsg.ne.jp>