Abstract FilePath Proposal

[amindfv at gmail.com]

El Jul 4, 2015, a las 15:26, Sven Panne <svenpanne at gmail.com> escribió:

> 2015-07-04 4:28 GMT+02:00 Carter Schonwald <carter.schonwald at gmail.com>:
>> [...] What fraction of currently build able hackage breaks with such an Api change, and how complex will fixing those breaks.  [...]
> 
> 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. 
> 
>> This should be evaluated.  And to what extent can the appropriate migrations be mechanically assisted. 
>> Would some of this breakage be mitigated by changing ++ to be monoid or semigroup merge? 
> 
> 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.

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.

Tom


> 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.
> 
> Cheers,
>    S.
> 
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150704/95774526/attachment.html>