On Wed, Apr 9, 2014 at 2:19 PM, Vincent Hanquez
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/d14f623833ce5bd3f6c5407e...
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