[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[MightyByte]

On Wed, Aug 15, 2012 at 9:19 PM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> On 16 August 2012 08:55, Brandon Allbery <allbery.b at gmail.com> wrote:
>> Indeed.  But the ghc release that split up base broke cabalised packages
>> with no warning to users until they failed to compile.  Upper bounds were
>> put in place to avoid that kind of breakage in the future.
>
> I like having upper bounds on version numbers... right up until people
> abuse them.

I also tend to favor having upper bounds.  Obviously they impose a
cost, but it's not clear to me at all that getting rid of them is a
better tradeoff.  I've had projects that I put aside for awhile only
to come back and discover that they would no longer build because I
hadn't put upper bounds on all my package dependencies.  With no upper
bounds, a package might not be very likely to break for incremental
version bumps, but eventually it *will* break.  And when it does it's
a huge pain to get it building again.  If I have put effort into
making a specific version of my package work properly today, I want it
to always work properly in the future (assuming that everyone obeys
the PVP).  I don't think it's unreasonable that some activation energy
be required to allow one's project to work with a new version of some
upstream dependency.

Is that activation energy too high right now?  Almost definitely.  But
that's a tool problem, not a problem with the existence of upper
bounds themselves.  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.  (Frankly, I think it would also be great if
Cabal/cabal-install enforced upper version bounds automatically if
none were specified.)  Another approach that has been discussed is
detecting dependencies that are only used internally[1], and I'm sure
there are many other possibilities.  In short, I think we should be
moving more towards purely functional builds that reduce the chance
that external factors will break things, and it seems like removing
upper version bounds is a step in the other direction.

[1] http://cdsmith.wordpress.com/2011/01/21/a-recap-about-cabal-and-haskell-libraries/