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



_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to