[#47033] [ruby-trunk - Bug #8749][Open] Readline.readline stops STDOUT? — "no6v (Nobuhiro IMAI)" <nov@...>
9 messages
2013/08/07
[#47036] Re: [ruby-trunk - Bug #8749][Open] Readline.readline stops STDOUT?
— Tanaka Akira <akr@...>
2013/08/07
2013/8/7 no6v (Nobuhiro IMAI) <nov@yo.rim.or.jp>:
[#47564] [ruby-trunk - Bug #8719][Open] r42096 make bm_app_factorial.rb slow — "authorNari (Narihiro Nakamura)" <authorNari@...>
4 messages
2013/08/02
[#47565] [ruby-trunk - Bug #8719] r42096 make bm_app_factorial.rb slow
— "authorNari (Narihiro Nakamura)" <authorNari@...>
2013/08/02
[#47569] [ruby-trunk - Feature #8726][Open] Class#source_location — "takiuchi (Genki Takiuchi)" <genki@...21g.com>
14 messages
2013/08/03
[#47574] Re: [ruby-trunk - Feature #8726][Open] Class#source_location
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/08/03
> Classオブジェクトが生成された場所を返す Class#source_location メソッドの実装を希望いたします。
[#47575] Re: [ruby-trunk - Feature #8726][Open] Class#source_location
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/08/03
> なるせさん、わたし、あのバックトレースの整形処理がイマイチ理解できんのだが、
[#47609] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio — Tanaka Akira <akr@...>
2013/8/12 <naruse@ruby-lang.org>:
7 messages
2013/08/12
[#47610] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio
— "NARUSE, Yui" <naruse@...>
2013/08/12
あぁ、[ruby-dev:47608]見てませんでした。
[#47611] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio
— Tanaka Akira <akr@...>
2013/08/12
2013年8月12日 11:38 NARUSE, Yui <naruse@airemix.jp>:
[#47614] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio
— "NARUSE, Yui" <naruse@...>
2013/08/12
editline の問題は、editlineにはrl_getcがなく、かつreadline.cで、
[#47620] Ruby 2.1 開発者会議 2013-08-31 のお知らせ — "NARUSE, Yui" <naruse@...>
かなり暑いですが、こんにちは。
5 messages
2013/08/14
[#47649] Re: [ruby-changes:30564] akr:r42643 (trunk): * process.c (rb_proc_times): Use RB_GC_GUARD to guard objects from GC. — SASADA Koichi <ko1@...>
akr さん
4 messages
2013/08/21
[#47650] Re: [ruby-changes:30564] akr:r42643 (trunk): * process.c (rb_proc_times): Use RB_GC_GUARD to guard objects from GC.
— Tanaka Akira <akr@...>
2013/08/21
2013/8/21 SASADA Koichi <ko1@atdot.net>:
[#47663] Re: [ruby-core:56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy — "Akinori MUSHA" <knu@...>
At Fri, 30 Aug 2013 21:49:34 +0900,
6 messages
2013/08/30
[#47664] Re: [ruby-core:56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/08/30
2013/8/30 Akinori MUSHA <knu@idaemons.org>:
[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 削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。 ではでは。