<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>El Jul 4, 2015, a las 15:26, Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>> escribió:</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-07-04 4:28 GMT+02:00 Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>[...] What fraction of currently build able hackage breaks with such an Api change, and how complex will fixing those breaks. [...]</div></blockquote><div><br></div><div>I think it is highly irrelevant how complex fixing the breakage is, it will probably almost always be trivial, but that's not the point: Think e.g. about a package which didn't really need any update for a few years, its maintainer is inactive (nothing to recently, so that's OK), and which is a transitive dependency of a number of other packages. This will effectively mean lots of broken packages for weeks or even longer. Fixing breakage from the AMP or FTP proposals was trivial, too, but nevertheless a bit painful. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This should be evaluated. And to what extent can the appropriate migrations be mechanically assisted. </div><div>Would some of this breakage be mitigated by changing ++ to be monoid or semigroup merge? </div></blockquote><div><br></div><div>To me the fundamental question which should be answered before any detail question is: Should we go on and continuously break minor things (i.e. basically give up any stability guarantees) or should we collect a bunch of changes first (leaving vital things untouched for that time) and release all those changes together, in longer intervals? That's IMHO a tough question which we somehow avoided to answer up to now. </div></div></div></div></div></blockquote><div><br></div><div>I'd argue that Haskell and GHC's history clearly shows we've answered that question and that overalll we value frequent small breaking changes over giant change roadblocks like Perl's or Python's. Still +0 on the proposal though.</div><div><br></div><div>Tom</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I would like to see a broader discussion like this first, both approaches have their pros and cons, and whatever we do, there should be some kind of consensus behind it.</div><div><br></div><div>Cheers,</div><div> S.</div><div><br></div><div>P.S.: Just for the record: I'm leaning towards the "lots-of-changes-after-a-longer-time" approach, otherwise I see a flood of #ifdefs and tons of failing builds coming our way... :-P</div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Libraries mailing list</span><br><span><a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a></span><br></div></blockquote></body></html>