Breakage with 6.10

[Simon Marlow]

Ian Lynagh wrote:
> On Fri, Oct 10, 2008 at 03:54:07PM -0700, Duncan Coutts wrote:
>> On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote:
>>> arrows fails due to:
>>>
>>>     [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o )
>>>
>>>     Control/Arrow/Transformer/CoState.hs:24:29:
>>>         Module `Control.Arrow' does not export `pure'
>>>
>>> Even though cabal-install decided to use base-3.0.3.0
>>>
>>> So that means base-3 is *not* exporting quite the same interface as last time.
>>> Were we aware of this?
>> Note that this means that base-3 should have the version number 3.1.x.y
>> because there is at least one incompatible api change. We're promoting
>> the versioning policy so we need to follow it ourselves in our base
>> libs.
> 
> I don't think that that really helps. If you're going to depend on base
> 3.1, you might as well just depend on base 4 and be more future-proof.
> The base-compat package needs to claim to have the same API as the old
> base, because the point is that things just keep on working (except in
> the few cases, like the Arrow split, where that isn't possible).

Hmm, this is quite annoying.  We simply *can't* provide the same API as 
base-3.0.2 without defining a new Arrow class, and that would kill 
compatibility with base-4.  On the other hand, we did know this could 
happen (changes to datatypes also cause the same problem), it's the 
tradeoff with trying to provide base-3 as a compatibility layer over base-4.

So the options are:

  * if we are honest and call it base-3.1, then everyone else has
    to lie and use dependencies like base==4.*.  If they use dependencies
    like base==4.0, which are more correct, then these packages will
    break in GHC 6.12 if we have to ship base-4.1 rather than 4.0.

  * we lie (a bit) and call it base-3.0.3.

so the total amount of dishonesty is reduced if we pick the second option :-)

Perhaps we've found a use for the second digit of the major version number.

Cheers,
	Simon