Gearing up (again) for the next release: 2014.2.0.0

[Gregory Collins]

On Wed, Apr 9, 2014 at 2:19 PM, Vincent Hanquez <tab at snarc.org> 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 <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140409/5cf942b2/attachment.html>