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