On Wed, Apr 9, 2014 at 2:19 PM, Vincent Hanquez <[email protected]> wrote:
> Last, I don't have the luxury of time, and as the single maintainer of 16 > packages of many thousands line of code (and many other packages if you > don't count tls/crypto), I'ld rather spend my free unpaid time doing > something useful (adding features, bugfixing,..) for the many currents > users [1], than playing the upper-bound-catch-up game. When those rare > breakage happens I get notification from the wonderful stackage and usually > fix it in the day or so. And re: this point: I don't have enough time for an epic mailing list flamewar today :), but I will say: - this behaviour makes life easier for you but causes many more build breakages for users - anecdotally, the tls ecosystem has been responsible for more build breakages in Snap than any other package (pre-1.0 we pulled it in via http-conduit for SSL blackbox testing). Just last week I had to fix a breakage in our testsuite caused by lack of upper bound on "cryptocipher": https://github.com/snapframework/snap-server/commit/d14f623833ce5bd3f6c5407e7ae5fabfc459e0d5#diff-77227feb32e2e44fffb113ad977244a7R31--- and I can dig up lots of other examples - you don't get breakage notifications for packages that aren't on hackage And as a side note: please don't get me wrong, I am very happy that you guys are doing all this work for the community and publishing all of these nice high-quality packages, and I as a package author myself I appreciate how much time goes into bumping version bounds. I just wish we could solve that root issue with better tooling rather than mortgaging the future. Without upper bounds on deps, lim_{t -> ∞} P(build-ok) = 0 :( -- Gregory Collins <[email protected]>
_______________________________________________ Haskell-platform mailing list [email protected] http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
