GHC 7.8 release?
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Sun Feb 10 10:50:12 CET 2013
Simon Peyton-Jones <simonpj at microsoft.com>:
> If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints.
> Let me suggest once more a possible path, along the lines you suggest
> · For people who value stability: use the Haskell Platform. Ignore GHC releases.
> · For people who want as many features as possible: use GHC releases.
> · For people who want to live on the bleeding edge: build HEAD from source
> The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed. HP may perfectly sensibly skip an entire release entirely.
> In short, I think we already have the situation that you desire. Perhaps we just need to market it better?
> Or am I mistaken?
There is one kink: for GHC releases to be *useful* substitutes for the HP for people who want medium stability, they must not change (expect maybe add to) the APIs in GHC versions that do not coincide with HP releases.
Why? If they change APIs, many of the packages on Hackage will not build with these intermediate GHC releases, which makes them useless for anything, but testing GHC.
Otherwise, I am perfectly happy with your suggestion. However, this is not the status quo. All (major) GHC releases do break critical packages on Hackage.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs