[ruby-dev:42701] 1.9.x release and trunk branch policy

まつもとさん、Yugui さん
遠藤です。

trunk ブランチの扱いについて、確認と提案です。


http://www.ustream.tv/recorded/11236338
の 41 分頃、卜部さんからの質疑で、まつもとさんが trunk の扱いに
ついて

  - refinement は原則 trunk に突っ込む
  - trunk は 1.9.3 に通じる (?)
    (まつもとさん自身は 1.9.3 または 2.0 のどちらになるかわからない
     ともおっしゃってますが)

ということをおっしゃっています。しかし開発者会議の記録によると

http://redmine.ruby-lang.org/wiki/ruby/DevelopersMeeting20100827
> yugui: 1.9 branch should not be made
> if we have a compatibility issue on 1.9 and 2.0 development, then create 1.9 branch

と、矛盾する感じのことが書かれています。実際のところは、タイム
アップで明確な結論は出なかったと記憶しています。

# [ruby-core:33567] では前田さんが ruby_1_9 ブランチを求めてたり
# しますので、私だけが誤解していたわけでもない。はず。


まず確認ですが、

  - ruby_1_9 は当分切らない (少なくとも 1.9.3 リリースまでは)
  - trunk のブランチから次に出るリリースは 1.9.3
  - 1.9.x 中で互換性は壊れない (キーワードの追加とかはまずない)
    - 2.0 も compatible を目指すということですし

というのは確定ということでよいでしょうか。


例えば 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 であることを明示してリリース
してみるのは悪くないのではないかと思います。どうでしょうか。

-- 
Yusuke Endoh <[e-mail]>