<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.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.hoenzb
        {mso-style-name:hoenzb;}
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:1006175740;
        mso-list-type:hybrid;
        mso-list-template-ids:-1847305180 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 class="MsoNormal" style="margin-left:36.0pt">We seem to be circling ever closer to consensus here! Yay!<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"><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">Indeed!&nbsp; Good :-)<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">However, I’m not getting the bit about API changing vs non-API changing.&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">Firstly I don’t know which APIs are intended.&nbsp; The GHC API is essentially GHC itself, so it changes daily.&nbsp; Maybe you mean the base package?&nbsp; Or what?&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">I suspect you mean that a “non-API-changing” release absolutely guarantees to compile any package that compiled with the previous version.&nbsp; If so, that is a
 very strong constraint indeed. We do observe it for patch releases for GHC (e g 7.6.2 should compile anything that 7.6.1 compiles).&nbsp; But I think it would be difficult to guarantee for anything beyond a patch release.&nbsp; Every single commit (and the commit rate
 is many/day) would have to be evaluated against this criterion.&nbsp; And if it failed the criterion, it would have to go on a API-breaking HEAD. In effect we’d have two HEADs.&nbsp; I can’t see us sustaining this.&nbsp; And I don’t yet really see why it’s necessary.&nbsp; If
 you don’t want an API-breaking change, stick with the patch releases.<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">So, we have a channel for non-API-breaking changes already: the patch releases.&nbsp; So that means we already have all three channels!<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">Haskell Platform<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">Patch-level 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">New releases<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"><br>
if that’s so, all we need is better signposting.&nbsp; &nbsp;And I’m all for that!<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">Have I got this right?<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"><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;"> Mark Lentczner [mailto:mark.lentczner@gmail.com]
<br>
<b>Sent:</b> 09 February 2013 17:48<br>
<b>To:</b> Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon Peyton-Jones; Mark Lentczner; andreas.voellmy@gmail.com; Carter Schonwald; kostirya@gmail.com; Edsko de Vries; ghc-devs@haskell.org; glasgow-haskell-users<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>
<div>
<div>
<p class="MsoNormal">We seem to be circling ever closer to consensus here! Yay!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta:<o:p></o:p></p>
</div>
<blockquote style="margin-left:24.0pt;margin-right:0cm">
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal"><b>Haskell Platform</b> comes out twice a year. It is based on very stable version of GHC, and intention is that people can just assume things on Hackage work with it. These are named for the year and sequence of the release: 2013.2, 2013.2.1,
 2013.4,...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</blockquote>
<blockquote style="margin-left:24.0pt;margin-right:0cm">
<div>
<p class="MsoNormal"><b>Non-API breaking releases</b> can come out as often as desired. However, the version that is current as of mid-Feb. and mid-Aug. will be the ones considered for HP inclusion. By non-API breaking we mean the whole API surface including
 all the libraries bundled with GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be explicitly enabled are okay. Additions of new APIs into existing modules are discouraged: Much code often imports base modules wholesale,
 and name clashes could easily result. These should never bump the major revision number: 7.4.1, 7.4.2...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal"><b>API breaking releases</b> happen by being released into a separate channel when ready for&nbsp;library&nbsp;owners to look at them. This channel should probably go through several stages: Ready for core package owners to work with, then HP package
 owners, then all package owners. I'd imagine this is a several month process. At the end of which, the release can go into the main channel. Such a merge shouldn't happen more than once a year... I think even once every two years is fine (!) To avoid confusion,
 I'd suggest that while in the separate channel, these release be named with odd number: 7.9, 7.11,..., and when moved to the main channel renamed to even: 7.10, 7.12...&nbsp;<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">This idea of three channels needs to be much more clearly communicated. The warning on the download page is a failure: Googling &quot;ghc&quot; takes you to the home page of GHC which immediately trumpets the &quot;Lastest News&quot; of a release of GHC 7.6.2.
 Once a user has read that and decided to download, then &quot;STOP!&quot; box is a) going to be skipped as they scan for the download link, and b) if read and followed, causes the &quot;WTF? Why is HP so back rev?&quot; So we need to change the front page so that the three channels
 are clearly communicated and targeted at the right users.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">- Mark<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">(BTW: The first few links on the GHC web site are out of date: The second nav link is to a survey that is 7 years old. The License page is 8 years out of date. The FAQ is over a year old.)<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh &lt;<a href="mailto:ian@well-typed.com" target="_blank">ian@well-typed.com</a>&gt; wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">On Sat, Feb 09, 2013 at 12:06:12PM &#43;0000, Simon Marlow wrote:<br>
&gt;<br>
&gt; As a straw man, let's suppose we want to do annual API releases in<br>
&gt; September, with intermediate non-API releases in February.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">That's a non-API release 5 months after the API release.<br>
<br>
6.10.2 was 5 &nbsp; months after 6.10.1 (.3 was 1 month later, .4 a further 2)<br>
6.12.2 was 4 &nbsp; months after 6.12.1 (.3 was 2 months later)<br>
&nbsp;7.0.2 was 3.5 months after &nbsp;7.0.1 (.3 was 1 month later, .4 a further 3)<br>
&nbsp;7.2.2 was 3 &nbsp; months after &nbsp;7.2.1<br>
&nbsp;7.4.2 was 4 &nbsp; months after &nbsp;7.4.1<br>
&nbsp;7.6.2 was 4.5 months after &nbsp;7.6.2<br>
<br>
so if we do non-API releases, then perhaps it would make sense to stop<br>
doing minor releases (unless a release turns out to just be broken).<br>
<br>
<br>
Thanks<br>
<span class="hoenzb"><span style="color:#888888">Ian</span></span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>