I was a bit hesitant about using this feature as well. We've had some confusion when we used it [1][2][3]. The Nix guys also seem to be having some trouble fitting it into their workflow [4]. But in [1] I did a quick grep to see how many packages used the feature, and there are already quite a lot. There is an 'x-revision' property added to the cabal file in the index, so in theory I guess tools could learn to deal with it. In general I think the biggest win for this feature is not even in relaxing bounds, but in tightening them when it turns out they're too loose. Previously cabal was always free to pick an old, unconstrained version and would often do so, leading to type errors during builds. Erik [1] https://github.com/silkapp/rest/issues/57 [2] https://github.com/silkapp/aeson-utils/issues/1 [3] https://github.com/silkapp/json-schema/issues/12 [4] https://github.com/NixOS/cabal2nix/issues/84 On Mon, Oct 27, 2014 at 8:30 PM, John MacFarlane <jgm@berkeley.edu> wrote:
I must say, I did pause a bit before making this change to pandoc on Hackage, precisely because I realized that the cabal file in the package would not match the one on Hackage.
But I went ahead, assuming that if the means were provided to make this kind of change, it should be okay.
It is time-consuming for me to make a proper pandoc release. I need to write up release notes, rebuild the website, generate and test the binary packages on various different platforms, upload to github releases and Hackage, send announcement emails, etc. Even with automation this all takes work. I'd rather not have to do this every time a version bound changes on a dependent package, so I like this way of making minor tweaks to version bounds; I hope I can be persuaded that it's not a bad idea.
John
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe