From: "NARUSE, Yui" Date: 2013-07-09T11:14:17+09:00 Subject: [ruby-core:55868] Re: ruby 1.9.3 p448 breaks ABI ABI should be kept over patch releases. Therefore ABI breakage is usually treated as a bug (except intended one like security related). But we didn't check ABI compatibility (as kosaki said, now we have one). So please report it, that's OSS way. If someone report it, it will be fixed. 2013/7/9 KOSAKI Motohiro : >> 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? > > Right. It's case by case thing. Example, when we find a security > issue, we don't hesitate to fix > it even if it can't be avoided ABI breakage. Another example, we > strongly want to keep zero gem breakage, but we don't mind internal > API even though the checker think it's exported symbol and a part of > ABI. In the other words, our stable tree focuses to maintain stable > ruby eco-system and it rarely mismatch strict ABI compatibility. If > anyone dislikes it, feel free to make and maintain your own > maintenance tree. > > In this case, it's on the border line because rb_f_lambda is > deprecated. If I was the maintainer, I didn't make the ABI breakage. > But please be aware, I and you are not the maintainer's employer. They > have a right to make and keep their branch maintenance policy. If you > want to help them, please do. But it's unfair if anyone who help > nothing blames them. They always did their best. > -- NARUSE, Yui