From: "NARUSE, Yui" Date: 2010-12-07T00:47:13+09:00 Subject: [ruby-dev:42703] Re: 1.9.x release and trunk branch policy 成瀬です。 (2010/12/07 0:34), Yusuke ENDOH wrote: > まず確認ですが、 > > - ruby_1_9 は当分切らない (少なくとも 1.9.3 リリースまでは) > - trunk のブランチから次に出るリリースは 1.9.3 > - 1.9.x 中で互換性は壊れない (キーワードの追加とかはまずない) > - 2.0 も compatible を目指すということですし > > というのは確定ということでよいでしょうか。 「1.9.x 中で互換性」の「互換性」を「後方互換性」にすれば理解通りです。 > 例えば refinement を experimental feature として 1.9.3 に含める > ことはいいと思うのですが、ChangeLog などに [experimental] などと > 書くだけだと既成事実で仕様化してしまい、API 変更は難しくなって > しまうと思います。 > 事実、ChangeLog には大量の [experimental] がありますが、今更変え > られないと思います。 > > $ grep -ci experimental ChangeLog doc/ChangeLog-1.9.3 > ChangeLog:6 > doc/ChangeLog-1.9.3:53 > > そこで、experimental であることを機能として示すのはどうでしょう。 > 具体的には、 > > 1. RubyVM.enable_experimental_feature というメソッドを呼ばないと > 使えない > 2. require "experimental.so" しないと使えない > 3. --experimental-feature というオプションを与えないと使えない > 4. experimental feature gem を入れないと使えない > 5. CFLAGS=-DEXPERIMENTAL_FEATURE でビルドしないと使えない > > などが考えられると思います。 > # 試用への障壁は 1 = 2> 3> 4> 5 だと思います。 > # コードのメンテナンス性としては 3 = 5> 1> 2> 4 でしょうか。 > これによって 1.9.x の安定だけでなく、正式仕様化の前に広く試用して > もらう期間ができ、言語設計の後悔が減る (といいな) と思っています。 > > > 「言語設計はまつもとさんの信念一発で決める！」という強権発動も嫌い > ではないですし最終的にはそれでいいと思うのですが、その判断のために > 広く意見を集めるために、experimental であることを明示してリリース > してみるのは悪くないのではないかと思います。どうでしょうか。 3, 5 は「Ruby はビルドによって挙動が異なるべきでない」という方針に反しますね。 一方で、1, 2 は Rails とかが内部で ON にするようにした時点で崩壊します。 4 でさえも Rails が experimental gem に依存した時点で終了でしょう。 というわけで、 6. experimental な feature では warning を出す を追加で -- NARUSE, Yui