On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net" target="_blank">gdr@integrable-solutions.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">I have some experience with GCC releases -- having served as a GCC</div></div>
Release Manager for several years. In fact, the release scheme we currently<br>
have has gone through several iterations -- usually after many "existential"<br>
crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't<br>
a research compiler and most "research works" are done on forgotten branches<br>
that nobody cares about anymore. Implementing new standards (e.g. moving<br>
from C++03 to C++11 that has several mandated API and ABI breakage) is a<br>
royal pain that isn't worth replicating in GHC -- at least if you want<br>
GHC to remain a research compiler.<br>
<br>
Concerning your question about release number, I would venture that there<br>
is a certain "marketing" aspect to it. I can tell you that we, the<br>
GCC community,<br>
are very poor at that -- otherwise, we would have been at version 26<br>
or something :-)<br></blockquote><div><br></div><div>Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else).</div>
<div><br></div><div>-- Johan</div><div> </div></div>