GHC 7.8 release?
ian at well-typed.com
Fri Feb 8 14:55:16 CET 2013
On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote:
> I wish GHC would radically change it's release process. Things like 7.8
> shouldn't be release as "7.8". That sounds major and stable. The web site
> will have 7.8 at the top. The warning to use the platform will fall flat
> because it makes the platform look out of date. Really, "7.8" should be in
> a different release channel, not on the front page. It should bake in that
> channel for six months - where only the third group of people will use it,
> until it is getting close to merge into main, at which point the fourth
> group will start to use it, so that the day it hits main, all the libraries
> just work. Ideally, the first two groups of people will not pay the
> slightest attention to it until it is further baked.
It's a catch-22: We don't want people to use a new release until all the
bugs have been found and fixed, and all the libraries have been updated.
But if people don't use it, then the bugs won't be found and the
libraries won't be updated.
I think you're saying that you'd like the uptake of new GHC versions to
be slower, which would mean fewer people would be using 7.6 now, but in
the last few days I've seen the Debian guys have had to send mails to
maintainers telling them that their packages don't work with 7.6:
despite 7.6 having been out for 5 months and about to enter the HP.
Perhaps more automatic Hackage building, with a group of people looking
at the logs of failing packages and acting appropriately, is the way
forward. Some cases (such as "installation failed due to dependencies
not being installable") you'd want to be handled automatically.
More information about the ghc-devs