GHC 7.8 release?

[Gabriel Dos Reis]

On Mon, Feb 11, 2013 at 5:03 PM, Johan Tibell <johan.tibell at gmail.com> 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? How about aiming for having GHC 7.10 be
> a release where we only add new stuff and improve old stuff?
>
> -- Johan
>
> * A major GCC release usually signifies that some large change to the code
> generator was made.

I have some experience with GCC releases -- having served as a GCC
Release Manager for several years. In fact, the release scheme we currently
have has gone through several iterations -- usually after many "existential"
crisis.  Yes, we don't break GCC ABI lightly, mostly because GCC isn't
a research compiler and most "research works" are done on forgotten branches
that nobody cares about anymore.  Implementing new standards (e.g. moving
from C++03 to C++11 that has several mandated API and ABI breakage) is a
royal pain that isn't worth replicating in GHC -- at least if you want
GHC to remain a research compiler.

Concerning your question about release number, I would venture that there
is a certain "marketing" aspect to it.  I can tell you that we, the
GCC community,
are very poor at that -- otherwise, we would have been at version 26
or something :-)

-- Gaby