<p dir="ltr">+10^100 to Johan and Manuel. Breaking changes on pieces that aren't experimental is the main compatibility / new version pain, </p>
<p dir="ltr">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. </p>
<p dir="ltr">If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. 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. </p>
<p dir="ltr">-Carter</p>
<div class="gmail_quote">On Feb 8, 2013 9:05 PM, "Manuel M T Chakravarty" <<a href="mailto:chak@cse.unsw.edu.au">chak@cse.unsw.edu.au</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>Manuel</div><br><div><div>Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>>:</div><blockquote type="cite"><div class="gmail_quote">On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>For a while we've been doing one major
release per year, and 1-2 minor releases. We have a big sign at
the top of the download page directing people to the platform. 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. 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. All that updating of packages
collectively costs the community a lot of time, for little
benefit. Lots of package updates contributes to Cabal Hell. 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. 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.
We're getting too efficient at making releases!<br></div></div></blockquote><div><br></div><div>I think we want to decouple GHC "major" releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or "big") releases, but rarely, if ever, break programs.</div>
<div><br></div><div>I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them.</div><div><br></div><div>-- Johan</div></div></blockquote></div><br></div>
</blockquote></div>