From: KOSAKI Motohiro Date: 2013-08-30T23:46:13-04:00 Subject: [ruby-dev:47670] Re: [ruby-core:56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy >> えっ。 >> いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。 > > はい。意味を変えるという提案なので。仮に 2.0 系列に新しいスキームを適用 > していたとすると、パッチレベルリリースは半年ちょっと経ちましたがまだ2回 > だけなので現在 2.0.2 になっており、仮に年内にあと2回くらい機能追加を含 > むリリースを出したとして 2.0.4、そこで 2.1.0 が出て、前方互換性を改善す > る機能追加や拡張を行いましょうというときにあと5回変身を残している感じで > す。十分ではないでしょうか。（後方非互換性については後述） > >> あと、Rubyのクラスは「開いている」ので、どんなバグフィックスであってもあやしげなモンキーパッチャーさんはぎゃっというリスクはあるわけで、このルールだとパッチレベルだけですむケースがほぼ無くなるんじゃないかなあ。 > > パッチレベルだけで済まない変更を加えた上でのリリースの余地が9回あれば、 > 現在のリリースサイクルを見るに十分ではないかというのが主旨です。 ちょっと自身がなかったので1.8.7のリリース回数を調べてみたのですがp0と合わせて22回 リリースが行われています。 いくつかはパッチレベルに出来るのでしょうが、9回あれば楽勝というレベルかというと ちょっと自身が持てませんでした。 前回のメールで書いたとおり、rubyレベルの変更が１つでも入ったらTEENYをbumpしないと いけない提案に見えるためです。 [ ] ruby-1.8.7-p17.tar.bz2 10-Jun-2008 03:40 3.9M [ ] ruby-1.8.7-p22.tar.bz2 21-Jun-2008 03:30 3.9M [ ] ruby-1.8.7-p71.tar.bz2 08-Aug-2008 20:09 3.9M [ ] ruby-1.8.7-p72.tar.bz2 11-Aug-2008 18:40 3.9M [ ] ruby-1.8.7-p160.tar.bz2 09-Apr-2009 22:44 3.9M [ ] ruby-1.8.7-p173.tar.bz2 10-Jun-2009 17:50 4.0M [ ] ruby-1.8.7-p174.tar.bz2 16-Jun-2009 17:58 4.0M [ ] ruby-1.8.7-p248.tar.bz2 25-Dec-2009 03:37 4.0M [ ] ruby-1.8.7-p249.tar.bz2 11-Jan-2010 04:32 4.0M [ ] ruby-1.8.7-p299.tar.bz2 24-Jun-2010 09:36 4.0M [ ] ruby-1.8.7-p301.tar.bz2 16-Aug-2010 21:43 4.0M [ ] ruby-1.8.7-p302.tar.bz2 17-Aug-2010 01:32 4.0M [ ] ruby-1.8.7-p330.tar.bz2 24-Dec-2010 21:33 4.0M [ ] ruby-1.8.7-p334.tar.bz2 19-Feb-2011 06:43 4.0M [ ] ruby-1.8.7-p352.tar.bz2 03-Jul-2011 03:54 4.0M [ ] ruby-1.8.7-p357.tar.bz2 29-Dec-2011 06:50 4.0M [ ] ruby-1.8.7-p358.tar.bz2 17-Feb-2012 03:01 4.0M [ ] ruby-1.8.7-p370.tar.bz2 30-Jun-2012 07:18 4.0M [ ] ruby-1.8.7-p371.tar.bz2 12-Oct-2012 22:32 4.1M [ ] ruby-1.8.7-p373.tar.bz2 28-Jun-2013 05:24 4.1M [ ] ruby-1.8.7-p374.tar.bz2 28-Jun-2013 05:57 4.1M [ ] ruby-1.8.7.tar.bz2 01-Jun-2008 09:19 3.9M > >> 開発陣におけるABI互換性についての意識は高まっているという認識にも懐疑的で、意識している人はしているししていない人は全然していないので、メンテナーの負荷を減らすにはコミッターの善意だけではだめでツールの助けがいるというのが >> ABI checker導入時のバックグラウンドモチベーションとしてありました。 > > そもそも現在API versionというのが実は何の役割も果たしていない（1.9でも > 2.0でもTEENYすら上がっていないし後方互換性も保たれていない）状況ですが、 > 少なくとも追加や拡張があるので上げるべき、削除や変更があるのでバックポー > ト不可、という判断がツールの支援である程度デジタルにできるようになりま > した。 そうですね。同意します > >> 実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。 >> >> というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり（rb_, >> ruby_ prefixの関数を自モジュールにつかう拡張が悪い）というRubyオレオレルールを継続することを提案します。 > > それだと、追加されたシンボルに依存したバイナリ物を配布するときにバージョ > ン番号でチェックできないのが困ります。ビルド時や実行時はextconf.rb や > respond_to? 等々でチェックもできますが、RubyGemsを含むパッケージシステ > ムがインストールの際にバージョン番号で比較するしかないというところにニー > ズがあります。 全然知らないのですが、gemはパッチレベルはチェックできないもの？ >> ついでに、いまはRubyレベルの非互換について、一切ツール支援がない状況ですので、こちらについても対策に関する意見を広く募集したいところです。 > > そうですね。そこは課題として認識します。 > >> >　 機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す >> > るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の >> > TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー >> > スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは >> > 主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が >> > 減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに >> > 応えるものです。 >> >> モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。 >> >> 実際の運用として、p0の後の最初の２つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり（どうせp0なんか使うやついないという判断により）、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。 > > 1.9.0 はプレビュー版、 1.9.1 はデベロッパー版みたいな感じでしたね。2.0 > 系列は、1.9での苦難のleapを果たした直後だけにうまく行きすぎているという > のはあります。 > >> これが、当初の２−３回のリリースはTEENYあげる。（Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような）小さな非互換もありうる。それ以降はパッチレベルでsymbol >> 削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。 > > 新しいスキームでも TEENY=0 くらいはプレビュー扱いで TEENY=1 で非互換も > あるよ、というのもいいかもしれません。少なくともどこからメンテナンス > フェーズか、非互換はあるか、という指針を内外に示すことが大事。 はい。細かいところで気になるところはありますが、総論としては賛成です。