GHC 7.8 release?

[Carter Schonwald]

Agreed.

having relatively bug free "technology preview" releases, which (perhaps
ideally) have new functionality included in a way that keeps the breakage
overhead lowish, on a regular basis, is ideal.

one thought on the api hacking front:

the main concern we're hitting is that we want to not "pin" internal GHC
apis, yet we want to make the breakage rate on libraries people may want to
use that might depend on say GHC.Prim or GHC.TH to be minimal.

Is a possible solution that on preview releases we have the changed bits of
API for a module M to be exported in a module M.Experimental?

eg, new ghc primops  in a tech preview release maybe are exported by
GHC.Prim.Experimental
(or something of this sort?)

just throwing out one possible point in the design space.

cheers
-Carter



On Mon, Feb 11, 2013 at 5:31 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  (a) There are packages which tend to track GHC's latest version instead
> of the HP (yesod used to do this, which was a source of much pain).****
>
>                                           ****
>
> (b) There are linux distributions which always track the latest
> everything, often in a rolling-release fashion (notably Arch).  They are
> actively hostile to the Platform, and a source of even greater pain.  Many
> package authors update because Arch users demand it and openly insult
> anyone who points them to the Platform or any policy which suggests that
> anything other then the absolutely latest version is acceptable.****
>
> ** **
>
> These must be *social* questions (what I was earlier calling
> “signposting”) rather than technical ones.  For example, you say that (b)
> is not subject to any variety of reason, and yet no linux distribution
> tracks HEAD, does it?  They don’t openly insult anyone who points to a
> release just because HEAD has new cool stuff!  No, they track things we
> call “releases”.  Very well, maybe we should call them “previews” instead,
> and only dignify it as a “release” when, and only when a preview is picked
> by HP as worthy of incorporation in the next HP. ****
>
> ** **
>
> Or something.   I’m just looking for a way to reconcile****
>
> **·        **Release early, release often****
>
> **·        **Stability for the Haskell Platform****
>
> It seems to me that such a reconciliation is within reach, and is actually
> very close to what we do, if we only signpost what is what far more
> vigorously and clearly than we do now.  But maybe I’m wrong.****
>
> ** **
>
> Simon****
>
> ** **
>
> *From:* Brandon Allbery [mailto:allbery.b at gmail.com]
> *Sent:* 11 February 2013 01:15
> *To:* Simon Peyton-Jones
> *Cc:* Simon Marlow; Mark Lentczner; Manuel M T Chakravarty;
> kostirya at gmail.com; glasgow-haskell-users; ghc-devs at haskell.org; Edsko de
> Vries
>
> *Subject:* Re: GHC 7.8 release?****
>
>  ** **
>
> On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:****
>
> What causes the "wave of package updates"?  Just because GHC 7.8 (say)
> comes out, no package author need lift a finger.  The Haskell Platform sets
> the pace for package updates. When the Haskell Platform comes out, now THAT
> is indeed a trigger for a wave of updates.  Authors of packages in HP are
> forced to act; authors of other packages want their packages to work with
> the next HP.****
>
>  ** **
>
> (a) There are packages which tend to track GHC's latest version instead of
> the HP (yesod used to do this, which was a source of much pain).****
>
>                                                     ****
>
> (b) There are linux distributions which always track the latest
> everything, often in a rolling-release fashion (notably Arch).  They are
> actively hostile to the Platform, and a source of even greater pain.  Many
> package authors update because Arch users demand it and openly insult
> anyone who points them to the Platform or any policy which suggests that
> anything other then the absolutely latest version is acceptable.****
>
> ** **
>
> You *might* be able to control expectations with respect to (a); (b) is
> not subject to any variety of reason.  It will produce as much pressure as
> it has users, plus multiply that pressure by the number of package authors
> who are also users.****
>
> ** **
>
> -- ****
>
> brandon s allbery kf8nh                               sine nomine
> associates****
>
> allbery.b at gmail.com
> ballbery at sinenomine.net****
>
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net****
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130211/c4f5f8e3/attachment.htm>