GHC 7.8 release?
marlowsd at gmail.com
Tue Feb 12 09:37:11 CET 2013
On 11/02/13 23:03, Johan Tibell wrote:
> 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
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
It would be great to have a list of the changes that had gone into base
in the last few major releases, any volunteers?
More information about the ghc-devs