GHC 7.8 release redux

[Ben Gamari]

Recently I tried to parse the flurry of activity in the "GHC 7.8
release?" thread which started in early February[1]. This was quite a
long thread with a number of different facets. To avoid losing points in
the noise, I thought it might be useful to summarize the major points
(please comment if I've missed something major),

  * More steeping time was necessary for a stable 7.8 release

  * Core APIs change too quickly, we need to try harder to decouple
    API-breaking releases from releases with core compiler functionality

  * The solution for this might be the three channel approach proposed
    by Mark[2]

  * Splitting base further might help the reduce unnecessary
    breakages[3]. Work has continued in this direction since the thread
    concluded[4].

  * Tracking performance regression with periodic runs of nofib would be
    useful[5]

Quite a productive thread for a week of wallclock time. That being said,
if I'm not mistaken one matter is notably absent: what is the plan for
7.8? Will it admit API breakage? Should we establish a timeframe for getting
work in before a formal release candidate is cut?

Of course, "let's just wait and see" is a perfectly reasonable response
but it would be nice to see it clearly set down in writing to avoid
future confusion.

Cheers,

- Ben



[1] http://www.haskell.org/pipermail/ghc-devs/2013-February/000309.html
[2] http://www.haskell.org/pipermail/ghc-devs/2013-February/000386.html
[3] http://www.haskell.org/pipermail/ghc-devs/2013-February/000451.html
[4] http://hackage.haskell.org/trac/ghc/wiki/SplitBase
[5] http://www.haskell.org/pipermail/ghc-devs/2013-February/000332.html