On Tue, 9 Jul 2013 06:50:16 +0900
KOSAKI Motohiro <kosaki.motohiro / gmail.com> wrote:

> (7/8/13 5:36 PM), Vt Ondruch wrote:
> > Dne 8.7.2013 17:03, Yorick Peterse napsal(a):
> >> Out of curiosity, does this tool take into account deprecated/internal
> >> symbols? rb_f_lambda has been deprecated for a while now and didn't do
> >> anything but call "rb_block_lambda". The function still appears to be
> >> located in proc.c though.
> >>
> >> Yorick
> >>
> >
> > I know it was deprecated. Nevertheless, removal of the function
> > definition was definitely not needed. It fixes nothing while there is
> > tiny chance that it may break something.
> >
> > With my maintainer of Ruby for Red Hat Enterprise Linux hat, how am I
> > supposed to defend the need of rebase of Ruby to the latest point
> > release, when it introduces ABI breakage?
> 
> When you have your specific requirement, your should use your hand instead of us.
> Write a tool or watch a branch update by yourself.
> 
> We don't intent to break anything. But we don't guarantee it especially if it is out
> of our scope.
> 

Given that not all are native English speakers, I'd like to be 100% sure I understand what is meant by
"...it is out of our scope" with regards to ABI breakage by a point release.

I'm aware of the following wiki page that briefly mentions ABI

  https://bugs.ruby-lang.org/projects/ruby/wiki/ReleaseEngineering

but I'm not aware of any ruby-core doco describing what is "in scope" and "out of scope" regarding ABI compliance.

Does "...it is out of our scope" mean that ruby-core views point releases as "in scope" when the point releases
are "best efforts ABI compatible", but "100% (strict) ABI compatibility" for point releases is "out of scope",
or something else?

For example, for any 1.9.3pXYZ point release, does ruby-core view it as "out of scope" to be 100% 1.9.1 ABI compatible,
but "in scope" to be best efforts 1.9.1 ABI compatible?

Jon