GHC 7.8 release?

[wren ng thornton]

On 2/12/13 3:37 AM, Simon Marlow wrote:
> One reason for the major version bumps is that base is a big
> conglomeration of modules, ranging from those that hardly ever change
> (Prelude) to those that change frequently (GHC.*). For example, the new
> IO manager that is about to get merged in will force a major bump of
> base, because it changes GHC.Event.  The unicode support in the IO
> library was similar: although it only added to the external APIs that
> most people use, it also changed stuff inside GHC.* that we expose for a
> few clients.
>
> The solution to this would be to split up base further, but of course
> doing that is itself a major upheaval.  However, having done that, it
> might be more feasible to have non-API-breaking releases.

While it will lead to much wailing and gnashing of teeth in the short 
term, if it's feasible to break GHC.* off into its own package, then I 
think we should. The vast majority of base seems quite stable or else is 
rolling along at a reasonable pace. And yet, every time a new GHC comes 
out, there's a new wave of fiddling the knobs on cabal files because 
nothing really changed. On the other hand, GHC.* moves rather quickly. 
Nevertheless, GHC.* is nice to have around, so we don't want to just 
hide that churning. The impedance mismatch here suggests that they 
really should be separate packages. I wonder whether GHC.* should be 
moved in with ghc-prim, or whether they should remain separate...

But again, this depends on how feasible it would be to actually split 
the packages apart. Is it feasible?

-- 
Live well,
~wren