[#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:47670] 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-31 03:46:13 UTC
List: ruby-dev #47670
>> えっ。
>> いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。
>
> はい。意味を変えるという提案なので。仮に 2.0 系列に新しいスキームを適用
> していたとすると、パッチレベルリリースは半年ちょっと経ちましたがまだ2回
> だけなので現在 2.0.2 になっており、仮に年内にあと2回くらい機能追加を含
> むリリースを出したとして 2.0.4、そこで 2.1.0 が出て、前方互換性を改善す
> る機能追加や拡張を行いましょうというときにあと5回変身を残している感じで
> す。十分ではないでしょうか。(後方非互換性については後述)
>
>> あと、Rubyのクラスは「開いている」ので、どんなバグフィックスであってもあやしげなモンキーパッチャーさんはぎゃっというリスクはあるわけで、このルールだとパッチレベルだけですむケースがほぼ無くなるんじゃないかなあ。
>
> パッチレベルだけで済まない変更を加えた上でのリリースの余地が9回あれば、
> 現在のリリースサイクルを見るに十分ではないかというのが主旨です。

ちょっと自身がなかったので1.8.7のリリース回数を調べてみたのですがp0と合わせて22回
リリースが行われています。
いくつかはパッチレベルに出来るのでしょうが、9回あれば楽勝というレベルかというと
ちょっと自身が持てませんでした。

前回のメールで書いたとおり、rubyレベルの変更が1つでも入ったら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の後の最初の2つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり(どうせp0なんか使うやついないという判断により)、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。
>
> 1.9.0 はプレビュー版、 1.9.1 はデベロッパー版みたいな感じでしたね。2.0
> 系列は、1.9での苦難のleapを果たした直後だけにうまく行きすぎているという
> のはあります。
>
>> これが、当初の2−3回のリリースはTEENYあげる。(Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような)小さな非互換もありうる。それ以降はパッチレベルでsymbol
>> 削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。
>
> 新しいスキームでも TEENY=0 くらいはプレビュー扱いで TEENY=1 で非互換も
> あるよ、というのもいいかもしれません。少なくともどこからメンテナンス
> フェーズか、非互換はあるか、という指針を内外に示すことが大事。

はい。細かいところで気になるところはありますが、総論としては賛成です。

In This Thread

Prev Next