GHC 7.8 release?

[Simon Marlow]

On 11/02/13 23:03, Johan Tibell wrote:
> Hi,
>
> I think reducing breakages is not necessarily, and maybe not even
> primarily, an issue of releases. It's more about realizing that the cost
> of breaking things (e.g. changing library APIs) has gone up as the
> Haskell community and ecosystem has grown. We need to be conscious of
> that and carefully consider if making a breaking change (e.g. changing a
> function instead of adding a new function) is really necessary. Many
> platforms (e.g. Java and Python) rarely, if ever, make breaking changes.
> If you look at  compiler projects (e.g. LLVM and GCC) you never see
> intentional breakages, even in major releases*. Here's a question I
> think we should be asking ourselves: why is the major version of base
> bumped with every release? Is it really necessary to make breaking
> changes this often?

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.

Of course we do also make well-intentioned changes to libraries, via the 
library proposal process, and some of these break APIs.  But it wouldn't 
do any harm to batch these up and defer them until the next API-changing 
release.

It would be great to have a list of the changes that had gone into base 
in the last few major releases, any volunteers?

Cheers,
	Simon