haskell-jp / random #95 at 2021-11-19 19:26:47 +0900

まだリリースされてないバージョンを依存の上限に指定するの、意味あるのかなあ（と思いながらがっつり削除する PR 作った
https://github.com/Deewiant/glob/pull/44

リリースされた瞬間ビルドエラーになるのを防ぐためではなく？

Hackageってリビジョン機能があるんで、依存可能バージョンの拡張はbreaking changeではないけど依存可能バージョンの縮小はbreaking changeであると言うことを考慮して先にPVPでbreaking changeが導入されうるmajor versionは念のために排除しておくという慣習だと思っていました

が、違うのでしょうか？

合っていると思います。
パッケージPがパッケージAに上限を設定せず依存しているとき、Aに非互換な変更が入ると当然Pは壊れます。P側で修正して新しいリリースをしてもcabalのdependency solverが古いパッケージを選択すれば壊れるので、非互換かつ上限を指定していないすべてのPのバージョンに対して新しいリビジョンでAのバージョンの上限を指定していく必要があります。

ここら辺が昔、バージョン指定したくないstack陣営と、正確なバージョン指定をしたいcabal陣営で意見が割れていた元凶でもあります

またhackage trusteesの人たちの仕事の一部でもあります

パッケージPがパッケージAに上限を設定せず依存しているとき、Aに非互換な変更が入ると当然Pは壊れます。P側で修正して新しいリリースをしてもcabalのdependency solverが古いパッケージを選択すれば壊れるので、非互換かつ上限を指定していないすべてのPのバージョンに対して新しいリビジョンでAのバージョンの上限を指定していく必要があります。

なるほど！
a.b.c のバージョンをリリースしたらそれより古い a.b.d のバージョンをメンテナンスする意識がなかったですね
互換性があるのだから a.b.x の x は最新を使えばいいという認識でした
自分がバージョン上限を撤廃したい理由としては、ほとんどの PR が上限撤廃の依頼で、手離れが悪いと思ったからですね
自分がライブラリー使う側だと 上限撤廃依頼への反応の悪いメンテナーにやきもきするというのもあります
（反応がないときは trustee に依頼すればよい？
stack 陣営 cabal 陣営で意見の対立があったのですか～

Trusteesはビルドが壊れていないかをなんらかの方法で見張っていて、影響が大きくかつメタデータの修正のみで直せるものは適宜リビジョンで対応してくれるという認識です。

最近この件で気づいたんですけど、依存パッケージの上限をつけないままアップロードしていると、Hackageでドキュメントが生成されない原因になるみたいで悩ましいですね。
（例えば https://hackage.haskell.org/package/autodocodec のを見るとaeson 2.0に対応できてないために失敗している）
もういっそCargoやnpmみたいに半自動で上限つけてほしい...（そうするとまた更新が面倒という問題に戻るんでしょうけど...

そういうパターンは rev を上げればいいのかな

依存パッケージ上限を追加した rev を

ただ、その方針だと

依存可能バージョンの縮小はbreaking changeである

のルールに反してしまうのが痛いですね。なんでそんなルールなのか私は分かってませんが...
https://haskell-jp.slack.com/archives/C4M4TT8JJ/p1637318867128600?thread_ts=1637317607.124900&cid=C4M4TT8JJ

あー:confounded:

A-1.1.0のdependency B-1.1.9のbreaking change B-1.2.0によってA-1.1のbuildが失敗する場合はAのversion constraint制限追加ってbreaking changeでもなんでもないですけど、B-1.2.0のbreaking changeが単なる動作変更であるがために、A-1.1の動作が単に変わる場合もあり得ますよね。それでドキュメントでライブラリユーザ向けにAが行った契約が破られる場合、契約を守るためにはAのversion constraintを制限しなければならないけど、これってライブラリユーザからすれば「使えていた組み合わせが使えなくなる」変化ですね。

特に、executableが動作の安定性を保証するために B==1.2.0,A==1.1.0 でリリースしていた場合とかが目も当てられない

なるほど。その論点だと、「ビルドが失敗するような事態になったら依存可能バージョンの縮小はOK」という例外規定があるとよいような気がするんですがいかがでしょうか？今問題にしているケースってまさに「A-1.1.0のdependency B-1.1.9のbreaking change B-1.2.0によってA-1.1.0のbuildが失敗する場合」は「A-1.1.0にB < 1.2.0を加えよう」という話なので

あってもいいんですが、Major dependency constraintを仮置きするかしないか、という論点で言うと、「メジャーバージョンアップによって型によるコンパイル失敗を介さずに関数の挙動が変更される」のは未来の事象なので、起こるか起こらないかは神のみぞ知る、というのが非常にアレですね。

対処するためには仮置きして後から緩和しないといけない…

あー、私の言ったbreaking changeっていうのは出典があるわけではなくて、「既存パッケージのビルド可能性または挙動を変えうる変更」って意味ですねえ……。pvpに定義済みの用語としてbreaking changeがあるんで、同じ言葉をつかうべきでは無かったですね。すみません。