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

On 15/08/2012 21:44, Johan Tibell wrote:

On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery wrote:

...

So we are certain that the rounds of failures that led to their being *added* will never happen again?

It would be useful to have some examples of these. I'm not sure we had any when we wrote the policy (but Duncan would know more), but rather reasoned our way to the current policy by saying that things can theoretically break if we don't have upper bounds, therefore we need them.

I haven't read the whole thread (yet), but the main motivating example for upper bounds was when we split the base package (GHC 6.8) - virtually every package on Hackage broke. Now at the time having upper bounds wouldn't have helped, because you would have got a depsolver failure instead of a type error. But following the uproar about this we did two things: the next release of GHC (6.10) came with two versions of base, *and* we recommended that people add upper bounds. As a result, packages with upper bounds survived the changes. Now, you could argue that we're unlikely to do this again. But the main reason we aren't likely to do this again is because it was so painful, even with upper bounds and compatibility libraries. With better infrastructure and tools, *and* good dependency information, it should be possible to do significant reorganisations of the core packages. As I said in my comments on Reddit[1], I'm not sure that removing upper bounds will help overall. It removes one kind of failure, but introduces a new kind - and the new kind is scary, because existing working packages can suddenly become broken as a result of a change to a different package. Will it be worse or better overall? I have no idea. What I'd rather see instead though is some work put into infrastructure on Hackage to make it easy to change the depdendencies on existing packages. Cheers, Simon [1] http://www.reddit.com/r/haskell/comments/ydkcq/pvp_upper_bounds_are_not_our_...