CPANモジュールは依存モジュールのバージョンを固定しない方がいい

Perl界隈ではCarton周りのtoolchainが整ってきて「これからはsemantic versioningやー」みたいな意識が高まりそうですが、そういうルールに則ってバージョニングをするのは大いに結構だとは思うのですが、バージョン違いのモジュールを同一プロセスで共有するとかそういうことはPerlではできないのでどちらにせよ注意が必要です。

まあ、バージョン違いのモジュールを共有できたところで、バージョン違いのオブジェクトが変なところに渡って死ぬみたいな話もあったりなかったりするらしいので夢を見過ぎるのも良くないですね。

それとタイトルのとおりですが、CPANに上げるモジュールの場合はバージョンは固定したり最大バージョンを決めない方が良いでしょう。

例えば、

• Super::ORM が Mouse 2.0に固定依存
• Hyper::WAF が Mouse 3.0に固定依存

だったりすると、Super::ORMとHyper::WAFが同時に使えなくて悲しみに包まれます。

なので、CPANにあげるモジュールの依存関係に関しては従来通り、最低バージョンの指定に止め、もし非互換の修正が依存モジュールに入って壊れたら、すみやかに報告するなり追随するなりして対応するのが良いでしょう。それに変にバージョンを固定するよりかは、そうやってCPANのモジュールをテスト・報告しあいながらCPANのサイクルを回していくほうが結果的にみんなの幸せになるのではないでしょうか。

もし依存しているモジュールに非互換のアップデートが入って自分のモジュールが壊れてしまっても、頑張って新しいものについていきしょう。あまりにも頻繁に予告なく後方互換を崩すようなモジュールはPerl界では褒められたものではありませんので、依存をやめたほうがいいかもしれません。

また、自分のモジュールで後方互換を壊さざるを得なくなった場合は、

• Amon2やDancer2のように名前空間そのものを変えてしまう
• 名前空間を変えない場合は依存されているモジュールを調べて予め連絡しておく。公にもアナウンスを出す

といったことをしたほうが良いでしょう。

もちろん、バージョン固定を使わないほうがいいという話ではなく、自分のプロジェクトなどではバージョンは固定できるに越したことは無いので、その場合はガンガン活用していくと良いと思います。

CPANに上げるようなモジュールでも、依存されることを想定していないプロダクト、例えばコマンドラインツールだったり、単体のWebアプリケーション(Ukigumo::Server的なやつ)などに関しては固定しても許容はできるかもしれませんが、だとしても推奨はあまりされないでしょう。

引き続き後方互換を大事にするPerlの文化を尊重していきたいものです。(もちろん、誰も使ってないような機能は廃止していったほうが良いとは思いますが(isn'tとか)。)

最近は過去のバージョンとの互換性を無視したり、わざわざ互換性をなくすような動きが 流行しています。(中略)
この道の先にあるのは、狂気です。
http://perldoc.jp/pod/perlpolicy