Hello, I also completely agree with Bryan's point which is why I usually don't add upper bounds on the dependencies of the packages that I maintain---I find that the large majority of updates to libraries tend to be backward compatible, so being optimistic seems like a good idea. By the way, something I encounter quite often is a situation where two packages both build on Hacakge just fine, but are not compatible with each other. Usually it goes like this: 1. Package A requires library X >= V (typically, because it needs a bug fix or a new feature). 2. Package B requires library X < V (typically, because someone added a conservative upper bound that needs to be updated). Trying to use A and B together leads to failure, which is usually resolved by having to install B manually, and remove it's upper bound by hand. This is rather unfortunate, because not only it's inconvenient but, also, now there is no released version of package B that you can explicitly depend on. -Iavor On Mon, Aug 20, 2012 at 7:11 AM, Brent Yorgey <byorgey@seas.upenn.edu>wrote:
On Thu, Aug 16, 2012 at 06:07:06PM -0400, Joey Adams wrote:
On Wed, Aug 15, 2012 at 3:38 PM, Bryan O'Sullivan <bos@serpentine.com> wrote:
I propose that the sense of the recommendation around upper bounds in the PVP be reversed: upper bounds should be specified only when there is a known problem with a new version of a depended-upon package.
I, too, agree. Here is my assortment of thoughts on the matter.
Here's some bad news: with cabal 1.14 (released with Haskell Platform 2012.2), cabal init defaults to bounds like these:
build-depends: base ==4.5.*, bytestring ==0.9.*, http-types ==0.6.*
I'm not sure why you think this is "bad news". I designed this to conform exactly to the current PVP. If the PVP is changed then I will update cabal init to match.
-Brent
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe