#shelarcyさんの「本物のプログラマは〜」には「Haskellコミュニティでは，互換性を保ちつつ新しい機能（API）を追加するときに三つ目の数字を上げます。」という文章がありますが、これってパッケージ群についても言えると思っていいでしょうか？
#つまり*.cabalのBuild-dependsセクションを書くときに、もしhogeパッケージが2.3.0.1とかなってたら hoge >= 2.3.0 && < 2.3.1みたいに設定するというのが基本だと思っていい？という質問ですが。
#APIはこの間は変わらない、というのがHaskellコミュニティ的な感覚だと考えていいのかな。
#あ、ちなみに引用は第39回「一般向けの「Haskell Platform」とインストール・ツールの「cabalコマンド」」です
###こんな文書でHackageのバージョン番号についてのポリシーが決められているみたいです。
#別件なのですが、筑波でDebian+Haskellな発表をすることになっていて、cabalの問題点についてまとめています。
##今のところ↑のみたいに書いてみたのですが、あからさまな間違いがないか軽くレビューしていただける優しい方はいらっしゃらないでしょうか。。。
#あと、個人的な感覚ですが、Hackageが依存したHackageのバージョン上限を規定するのは悪い慣習だと思っています。。。
#おお、これです。書いてありますね。
#確かにcabalが依存関係を確認する上でOrdとして判断できる必要とかあるから、そこは最低取り決めが必要になるわけですね。
#上限が無かったら現時点で最新のを使うってことですか？
それは困りませんか？
#cabalを使っていて問題になる点の一つとして、メンテが弱いHackageが古いHackageに依存されたまま放置されてしまうことがあると思います。
#ちなみに私はバージョン番号では無くライブラリのAPIからハッシュ値を算出して、そのハッシュ値を使って欲しいかな。
#たしかに、自分のHackageが依存しているAPIが削除されるのを防止するためには上限を決めたくなります。
#でもAPIが削除されれば、そもそもコンパイルエラーになるんだと思っています。そうであれば、そもそもバージョン番号で規定しなくてもいいんではないかと。
#もっともAPIだけ先祖返りするとかAPIが変わらなかった時にどちらがマイナーバージョン的に新しいか分からなくなるのでHackageにアップした時点でシリアルに番号つけてもらわないと…だけど。
#そうすれば、メンテをサボっていて、依存しているHackageが高速に更新をくりかえしていても、エンドユーザは変なことにならないです。。。
#などとディストリビュータとしての意見を発散しますた
haskell-ja > Archives > 2011/10/13