[#47562] [Backport 200 - Backport #8716][Open] segmation fault 正規表現で大量のグループを利用時 — "taka-yoshi (taka-yoshi taka)" <smokeonthewater222@...>

15 messages 2013/08/01

[#47569] [ruby-trunk - Feature #8726][Open] Class#source_location — "takiuchi (Genki Takiuchi)" <genki@...21g.com>

14 messages 2013/08/03

[ruby-dev:47664] Re: [ruby-core:56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy

From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2013-08-30 23:49:59 UTC
List: ruby-dev #47664
2013/8/30 Akinori MUSHA <knu@idaemons.org>:
> At Fri, 30 Aug 2013 21:49:34 +0900,
> I wrote:
>> misc #8835: Introducing a semantic versioning scheme and branching policy
>> https://bugs.ruby-lang.org/issues/8835
>
>  DevelopersMeeting20130831Japanでのプレゼンのために、[ruby-core:56878]
> [misc #8835] を日本語で補足します。
>
>  直接的なきっかけは [ruby-list:49555] のスレッドです。元の問題自体は、
> RubyGemsを直すべきだと思います。ただ、1.8, 1.9, 2.0と、バージョンの運用
> 状況が毎回なんとなしに変わってきており、PATCHLEVELまであるRUBY_VERSION
> がAPI互換性については多くを示さず、RUBY_API_VERSIONが別途あるというのは
> ちょっといただけない状況だと思いました。
>
>  そこで、この提案は [MAJOR & MINOR, TEENY, PATCHLEVEL] がSemantic
> Versioning (http://semver.org/)に沿うように再定義しようというものです。
> Ruby自体をAPI互換性を考慮したバージョン体系にすることによって、1.9で導
> 入されたもののあまり有意義に運用されなかったRUBY_API_VERSIONと統一し、
> 両者の不一致から来る潜在的なユーザの混乱および互換性に関する懸念の解消
> を図ります。
>
>  開発陣におけるABI互換性についての意識は高まっており、試験的ながら
> Ruby-CIにもABIチェックが入っているので、Semantic Versioningを運用してい
> くことが現実的に可能だと思います。
>
>  TEENYが9までしか使えないという縛りはありますが、MAJOR.MINOR.0のリリー
> ス後に、APIを追加・拡張したリリースを9回も行う必要は薄く、いつでも追加・
> 拡張をやめてバグ修正のみのフェーズに移行できるので、枯渇を気にする必要
> はないでしょう。

えっ。
いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。

あと、Rubyのクラスは「開いている」ので、どんなバグフィックスであってもあやしげなモンキーパッチャーさんはぎゃっというリスクはあるわけで、このルールだとパッチレベルだけですむケースがほぼ無くなるんじゃないかなあ。

開発陣におけるABI互換性についての意識は高まっているという認識にも懐疑的で、意識している人はしているししていない人は全然していないので、メンテナーの負荷を減らすにはコミッターの善意だけではだめでツールの助けがいるというのが
ABI checker導入時のバックグラウンドモチベーションとしてありました。

実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。

というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり(rb_,
ruby_ prefixの関数を自モジュールにつかう拡張が悪い)というRubyオレオレルールを継続することを提案します。

ついでに、いまはRubyレベルの非互換について、一切ツール支援がない状況ですので、こちらについても対策に関する意見を広く募集したいところです。

>
>  機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す
> るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の
> TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー
> スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは
> 主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が
> 減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに
> 応えるものです。

モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。

実際の運用として、p0の後の最初の2つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり(どうせp0なんか使うやついないという判断により)、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。
これが、当初の2−3回のリリースはTEENYあげる。(Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような)小さな非互換もありうる。それ以降はパッチレベルでsymbol
削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。

ではでは。

In This Thread