Lucas Nussbaum <lucas / lucas-nussbaum.net> wrote:
> Even if 1.9.3 is still binary-compatible with 1.9.1,

There are symbol visibility changes with newer GCC that break
things for extensions relying on functions not declared in
public headers.  I have issue #4328 open for one case I hit.

> - advertise the fact that there are API changes in 1.9.3 that could
> break apps

Extensions relying on accessing members of rb_io_t buffers (exported in
ruby/io.h) won't rebuild under 1.9.3 if they were built for 1.9.2.  No
ABI breakage for already built extensions from the looks of it, though.
ref: r29826[1].

There may be other examples, but I don't remember...


I agree with Lucas that the compatibility version should be raised

Backwards compatibility is too much work if it slows down progress and
improvements that could be made in Ruby 1.9.

The Ruby ecosystem is mostly Free Software and fixable by users.  While
API compatibility is often justified (developer time needed to update
software) and ABI compatibility is /way/ too much work if a rebuild can
fix it.


[1] - My personal take on most structures such as rb_io_t is to make it
      opaque and have stable functions access them, but that's a lot
      of work.
-- 
Eric Wong