<p dir="ltr">Well said. Having a more aggressive release cycle is another interesting perspective. </p>
<div class="gmail_quote">On Feb 10, 2013 6:21 PM, "Gabriel Dos Reis" <<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>> 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 <<a href="mailto:ian@well-typed.com">ian@well-typed.com</a>> wrote:<br>
> On Sun, Feb 10, 2013 at 09:02:18PM +0000, Simon Peyton-Jones wrote:<br>
>><br>
>> You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested.<br>
><br>
> But the way you test new features is to write programs that use them,<br>
> and programs depend on libraries.<br>
><br>
><br>
> Thanks<br>
> Ian<br>
<br>
Releasing GHC early and often (possibly with API breakage) isn'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">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>