Simon Peyton-Jones <simo...@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. Manuel
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
