<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Verdana","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:460925988;
        mso-list-type:hybrid;
        mso-list-template-ids:1462634372 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p style="margin-left:36.0pt">If there's a path to having a release strategy as Manuel suggests, and having an intermediate release&nbsp; with the new vector primops, type extensions and such goodness, then I'm all for it.&nbsp; 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.
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D">Let me suggest once more a possible path, along the lines you suggest<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D">For people who value stability: use the Haskell Platform.&nbsp; Ignore GHC releases.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D">For people who want as many features as possible: use GHC releases.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D">For people who want to live on the bleeding edge: build HEAD from source<o:p></o:p></span></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D">The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed.&nbsp; HP may perfectly sensibly skip
 an entire release entirely.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D">In short, I think we already have the situation that you desire.&nbsp; Perhaps we just need to market it better?&nbsp;
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D">Or am I mistaken?<br>
<br>
Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Carter Schonwald [mailto:carter.schonwald@gmail.com]
<br>
<b>Sent:</b> 09 February 2013 02:45<br>
<b>To:</b> Manuel Chakravarty<br>
<b>Cc:</b> GHC Users List; ghc-devs@haskell.org; Andreas Voellmy; Simon Peyton-Jones; Edsko de Vries; Mark Lentczner; Johan Tibell; parallel-haskell<br>
<b>Subject:</b> Re: GHC 7.8 release?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p>&#43;10^100 to Johan and Manuel. Breaking changes on pieces that aren't experimental is the main compatibility / new version pain,
<o:p></o:p></p>
<p>and I say this as someone who's spent time before and around the 7.4 and 7.6 releases testing out lots of major packages and sending a few patches to various maintainers.
<o:p></o:p></p>
<p>If there's a path to having a release strategy as Manuel suggests, and having an intermediate release&nbsp; with the new vector primops, type extensions and such goodness, then I'm all for it.&nbsp; 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.
<o:p></o:p></p>
<p>-Carter<o:p></o:p></p>
<div>
<p class="MsoNormal">On Feb 8, 2013 9:05 PM, &quot;Manuel M T Chakravarty&quot; &lt;<a href="mailto:chak@cse.unsw.edu.au">chak@cse.unsw.edu.au</a>&gt; wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">I'm all for restricting major API changes to once a year, but why can't we have multiple updates to the code generator per year or generally release that don't affect a large number of packages on Hackage?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">Manuel<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<p class="MsoNormal">Johan Tibell &lt;<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>&gt;:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow &lt;<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>&gt; wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">For a while we've been doing one major release per year, and 1-2 minor releases.&nbsp; We have a big sign at the top of the download page directing people to the platform.&nbsp; We arrived here after various discussions in the past - there were always
 a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits.&nbsp; So we settled on one API-breaking change per year as a compromise.<br>
<br>
Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC.&nbsp; All that updating of packages collectively costs the community a lot of time, for little benefit.&nbsp; Lots
 of package updates contributes to Cabal Hell.&nbsp; The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready.<br>
<br>
So I think, if anything, there's pressure to have fewer major releases of GHC.&nbsp; However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months.&nbsp; We're getting too efficient at making releases!<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">I think we want to decouple GHC &quot;major&quot;&nbsp;releases&nbsp;(as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or &quot;big&quot;) releases, but rarely, if ever, break programs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">-- Johan<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>