From: "akira yamada / やまだあきら" Date: 2009-01-09T19:45:03+09:00 Subject: [ruby-dev:37748] $LOAD_PATHとバージョンの運用の関係 1.9系でのバージョンの運用と$LOAD_PATHの値について質問です。 1.9.1RC1のconfigure.inでは、Ruby本体のバージョンを $LOAD_PATHに埋め込んでいるように見えます。 デフォルトでは「1.9.1」のようにteenyまで含むものです。 このことにより、Ruby 1.9.2がリリースされたとき Rubyをバージョンアップすると、 バイナリかどうかによらずすべての外部ライブラリ (ユーザ作成のものも含む)が利用できなくなります。 もちろん、再インストールすれば良いわけですが、 このことからRuby 1.9系ではteenyが上がるごとに 互換性がなくなるような運用を想像してしまいます。 コアチームではこのあたりの運用をどのように考えているのでしょうか。 * と、いうことをIRCでたずねました。 IRC上では以下のような話になりました。 2009-01-09 13:31 というか、その辺の話はオフィシャルな場で議論していないので、ruby-devに投げるとよいかもしれませぬ 2009-01-09 13:32 ./configure.inがそうなってないのは、 2009-01-09 13:32 単にだれもやってないから。 2009-01-09 13:37 ircで話した結果の私の認識: 2009-01-09 13:37 バイナリ互換が破られたら1.9.1の部分がその時のバージョンに上がる! 2009-01-09 13:38 RubyレベルAPIはできるだけ上位互換性の方向で。 2009-01-09 13:38 (バイナリに依存しない.rbと分離可能だという気分はある) 2009-01-09 13:38 ということはLOAD_PATHはteenyを直接使ってはいけない? 2009-01-09 13:38 n0kada: 本当は。 2009-01-09 13:39 バイナリAPI仕様バージョン番号、が必要になるということだよね。 2009-01-09 13:39 RUBY_API_VERSIONとかが 2009-01-09 13:39 これは1.8の頃にも議論があったと記憶している。 2009-01-09 13:53 というわけで、今後新規に必要になるのは、shared objectのバージョン番号と、ライブラリインストールパスのバージョン番号 2009-01-09 13:54 という理解で正しいのでしょうか。 2009-01-09 13:55 libruby191になるのはだめなの？ 2009-01-09 13:56 だめじゃないんじゃね 2009-01-09 13:56 いいと思いますよ、要約してくださる方がいれば 2009-01-09 13:57 すると、Rubyのバイナリバージョン番号？ 2009-01-09 13:59 それから両方が決定できるなら。 2009-01-09 13:59 外見えで必要なのはさっきの2つ。内部的にそれを何から生成するかは別に何でも。 ざっくりまめると以下のような感じでしょうか。 * $LOAD_PATHの中の「1.9.1」の部分は、 本来的にはRubyのAPIバージョン的なものを表している * その部分はRubyのAPI互換性に応じて変わる(上がる) * *.soに依存している可能性から *.rbファイルも同様に互換性が失われる(と考える) この考え方からするとRubyレベルでの APIのバージョンを示すものが必要になりそうです (それがリリース時点のRubyのバージョンでも構わないと思います)。 また、それとは別に、1.9.xのどこかでバイナリ互換性が失われる 可能性があるそうですのでsonameの運用についても 何かしらの方針が必要なのではないかと思います。 APIバージョンおよび$LOAD_PATHの運用については おおざっぱな言い方になりますが業務で使う場合には けっこう重要になってくると思います。 (仮にconfigure.inが今のまま1.9.2になったとすると、 そのアップグレードはかなり難しくなります。) また、APIバージョンおよびsonameの両方について、 私的話になって申し分けないのですけども バイナリパッケージを作成する上でけっこう重要になってきます。 * そんなわけで、このあたりの運用方針について どこかで明確になっているとありがたいのですが、 いかがでしょうか。 -- ay