versioning hell

世間ではfirefox 1.0.5の日本語版が出せないとか言って騒ぎになっていますね。まあ、騒いでいる非モヒカン族（言葉を覚えたので使ってみたｗ）の大半は実は英語版でも問題なく使える人間か実はfirefox使ってない人間だと思いますが。

で、今回の件はAPIの安定性が問題だったわけですが、これって果たして解決できる問題なんでしょうかね。実際のところ、.NETのside by side executionというのは、そのような変更があっても問題なく動作させるための機構として提供されたはずなのですが、どうも.NET 1.1 -> 2.0の変遷を眺めていると、やっぱside by sideだけでは足らんのでしょうね。僕はいじったこと無いから知らないけど、WSEも結局全然違う物になってたっぽいし。複数バージョンを並行インストールできるJavaと比べて、あんまし大きな改善点は無かったようにも思えます。

Monoでは、API stabilityに関連して、Application Deployment Guidelineというドキュメントにガイドラインをまとめています。この中の「GACをいつ使うべきか」というセクションで、

But developers that install libraries into the GAC must be aware that putting something on the GAC is a commitment to API stability. It is a commitment that should not be taken lightly. If you are to change the API in a backwards-incompatible way, you should change the version of the library to ensure that old applications continue to work. When the library changes its version, then two copies of the library must be distributed: one for the old applications that might depend on the old API and the new version of the library.

と言われています。GACにライブラリをインストールするということは、APIが安定したものであるということを多かれ少なかれ約束したようなものだから、まだAPIが不安定なうちはGACにインストールなどするな、ということです。

Summer of Codeでばんばん改善されているmonodocでも、DotLuceneを使った検索機能が追加されようとしているんですが、どんだけ共用されていようとdotluceneのdllはGACにインストールしない方向でいくみたい。

まあGACについては、まだ@ITがおもしろかった頃に通常のアプリケーション用のアセンブリをGACにインストールする必要はまったくない、と既に言われていたことですし、あんまし関係ないはずですね。

MonoはGACのロケーションに関しては柔軟に指定できるのですが、インストール先の指定が問題になるのは、必ずしもglobal assemblyだけではないので、あまり複雑なことはしない方が吉なのでしょう。たとえば、WindowsユーザーはCodeDomProviderやASP.NETを使うとき、cscが内部で呼び出されるのは当たり前のことだと思っているかもしれませんが、Monoの場合はmcsにパスが通っているとは限りませんし、monoランタイムの位置からlibの位置を逆算できるとは限らないのです。それ以前に、環境によってインストールされるライブラリは異なりうるからmcsはデフォルトでmscorlib,System,System.Xml以外のライブラリは-rで明示的に参照しないといけないし、可愛いっぷり見せないといけないし…女の子は忙しいんです。