<div dir="ltr">While I&#39;m notionally in favor of decoupling API-breaking changes from non-API breaking changes, there are two major difficulties: GHC.Prim and Template Haskell. Should a non-API-breaking change mean that GHC.Prim is immutable?  If so, this greatly restricts GHC&#39;s development.  If not, it means that a large chunk of hackage will become unbuildable due to deps on vector and primitive.  With Template Haskell the situation is largely similar, although the deps are different.<div>
<br></div><div style>What I would like to see are more patch-level bugfix releases.  I suspect the reason we don&#39;t have more is that making a release is a lot of work.  So, Ian, what needs to happen to make more frequent patch releases feasible?</div>
<div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 7:42 AM, Carter Schonwald <span dir="ltr">&lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Well said. Having a more aggressive release cycle is another interesting perspective. </p><div class="HOEnZb">
<div class="h5">
<div class="gmail_quote">On Feb 10, 2013 6:21 PM, &quot;Gabriel Dos Reis&quot; &lt;<a href="mailto:gdr@integrable-solutions.net" target="_blank">gdr@integrable-solutions.net</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 3:16 PM, Ian Lynagh &lt;<a href="mailto:ian@well-typed.com" target="_blank">ian@well-typed.com</a>&gt; wrote:<br>
&gt; On Sun, Feb 10, 2013 at 09:02:18PM +0000, Simon Peyton-Jones wrote:<br>
&gt;&gt;<br>
&gt;&gt; You may ask what use is a GHC release that doesn&#39;t cause a wave of updates?  And hence that doesn&#39;t work with at least some libraries.  Well, it&#39;s a very useful 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;<br>
&gt; Thanks<br>
&gt; Ian<br>
<br>
Releasing GHC early and often (possibly with API breakage) isn&#39;t<br>
really the problem.  The real problem is how to coordinate with<br>
library authors (e.g. Haskell Platform), etc.<br>
<br>
I suspect GHC should continue to offer a platform for research<br>
and experiments. That is much harder if you curtail the ability to<br>
release GHC early and often.<br>
<br>
-- Gaby<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">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>
</div></div><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>
<br></blockquote></div><br></div>