[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
wren ng thornton
wren at freegeek.org
Fri Aug 17 05:33:17 CEST 2012
On 8/15/12 11:02 PM, MightyByte wrote:
> One tool-based way to help with this problem would
> be to add a flag to Cabal/cabal-install that would cause it to ignore
> upper bounds.
I'd much rather have a distinction between hard upper bounds ("known to
fail with") vs soft upper bounds ("tested with").
Soft upper bounds are good for future proofing, both short- and
long-range. So ignoring soft upper bounds is all well and good if things
However, there are certainly cases where we have hard upper
bounds, and ignoring those is not fine. Circumventing hard
upper bounds should require altering the .cabal file, given as getting
things to compile will require altering the source code as well. Also,
hard upper bounds are good for identifying when there are
semantics-altering changes not expressed in the type signatures of an
API. Even if relaxing the hard upper bound could allow the code to
compile, it is not guaranteed to be correct.
The problem with the current policy is that it mandates hard upper
bounds as a solution to the problem of libraries not specifying soft
upper bounds. This is indeed a tooling problem, but let's identify the
problem for what it is: not all upper bounds are created equally, and
pretending they are only leads to confusion and pain.
 Parsec 2 vs 3, for a very long time
 mtl 1 vs 2, for a brief interim
 John Lato's iteratee <=0.3 vs >=0.4, for legacy code
More information about the Haskell-Cafe