[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
marlowsd at gmail.com
Mon Aug 20 15:24:56 CEST 2012
On 15/08/2012 21:44, Johan Tibell wrote:
> On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery <allbery.b at gmail.com> 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
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, 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
More information about the Haskell-Cafe