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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
