[Haskell] Re: Trying to install binary-0.4

[Simon Marlow]

Simon Marlow wrote:

> Probably it could be made clearer.  In 4.2 the idea is that instead of 
> replacing
> 
>  base-2.0 ==> base-3.0 + directory-1.0 + array-1.0 + ...
> 
> you would replace
> 
>  base-2.0 ==> newbase-1.0 + directory-1.0 + array-1.0 + ...
 >
> and additionally have a package base-3.0 that re-exports the whole of 
> (newbase + directory + array + ...).  


There's another alternative, that Simon PJ pointed out to me this morning. 
  Actually I think this is rather nice, as it solves the problem of having 
to rename base for each split.

Let's suppose that in GHC 6.10 we want to split some modules from base 
again (highly likely).  So we make this change, for example:

    base-3.0 ===> base-4.0 + concurrent-1.0 + generics-1.0

note that the new, smaller, base is called base-4.0.

Then, we provide a wrapper package base-3.1, that re-exports (base-4.0 + 
concurrent-1.0 + generics-1.0).  Why is it called 3.1, not 3.0?  Because 
almost certainly by the time GHC 6.10 is released there will be some API 
changes in these packages too, and we aren't trying to reproduce the 
base-3.0 API exactly (that's proposal 4.1).  This amounts to adopting a 
convention for the base package that changes in the first component of the 
version indicate splits or removal of modules, and changes to the second 
component indicate other API changes only.

The idea is that all packages on Hackage will be using precise dependencies 
by this point, so they will all have something like

   build-depends: base-3.0.*

Now, when GHC 6.10 is released, the majority of these packages will build 
again if the .cabal file is changed to say

   build-depends: base >= 3.0 && <= 3.1

rather than introducing conditional dependencies as was necessary with the 
recent base split.  In due course, packages can be upgraded to depend on 
the new base-4.0.

I'll call this proposal 4.3 and add it to the wiki.  It seems like a pretty 
good compromise to me.

Cheers,
	Simon