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@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@gmail.com]
Sent: 11 February 2013 01:15
To: Simon Peyton-Jones
Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kostirya@gmail.com; glasgow-haskell-users; ghc-devs@haskell.org; Edsko de Vries


Subject: Re: GHC 7.8 release?

 

On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <simonpj@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@gmail.com                                  ballbery@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs