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