<p dir="ltr">Yes, exactly this. </p>
<p dir="ltr">A release where the versions of base, and all other baked in libraries are only minor version bumps and where breaking changes are localized to relatively experimental language features / extensions and GHC specific APIs would ideal.  </p>

<p dir="ltr">Eg: I&#39;m OK having to patch ghc-mod so it works with a new intermediate GHC release.  (Esp since it uses GHC internal apis)<br></p>
<p dir="ltr">The new scheduler improvements, the recent doh work  , the great SIMD work / code generator improvments, the type level nats, ordered type families,  the overloaded list syntax, </p>
<p dir="ltr">All of these extensions and associated API augmentations should not break stable libraries, at least on minor version bumps, cause<br>
 1) maybe experimental new APIs can be included in minor releases as separate explicitly experimental modules (this gives a way of including new functionality in a minor release)<br>
2) generally type checking / inference on stable code that doesn&#39;t enable new features stays the same. </p>
<p dir="ltr">I&#39;m probably overlooking some pieces or. Details, and I&#39;m largely restating what Johan and Manuel have communicated. </p>
<p dir="ltr">-Carter <br></p>
<div class="gmail_quote">On Feb 10, 2013 4:43 PM, &quot;Ian Lynagh&quot; &lt;<a href="mailto:ian@well-typed.com">ian@well-typed.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Feb 10, 2013 at 09:30:23PM +0000, Simon Peyton-Jones wrote:<br>
&gt; |  &gt; You may ask what use is a GHC release that doesn&#39;t cause a wave of updates?<br>
&gt; |  And hence that doesn&#39;t work with at least some libraries.  Well, it&#39;s a very useful<br>
&gt; |  forcing function to get new features actually out and tested.<br>
&gt; |<br>
&gt; |  But the way you test new features is to write programs that use them,<br>
&gt; |  and programs depend on libraries.<br>
&gt;<br>
&gt; That is of course ideal, but the ideal carries costs.  A half way house is a release whose library support will be patchy.<br>
<br>
But that&#39;s not what happens. GHC 7.8 is released. Someone installs it in<br>
order to try to use TypeHoles when developing their program. But their<br>
program depends on text, so they send Bryan a mail saying that text<br>
doesn&#39;t build with 7.8. And so the wave of updates begins.<br>
<br>
<br>
Thanks<br>
Ian<br>
<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>