Re: Gearing up (again) for the next release: 2014.2.0.0

On 2014-04-09 13:46, Gregory Collins wrote:

On Wed, Apr 9, 2014 at 2:19 PM, Vincent Hanquez mailto:tab@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/d14f623833ce5bd3f6c5407e... --- and I can dig up lots of other examples * you don't get breakage notifications for packages that aren't on hackage

[Dropping the platform list, as it's offtopic there] You could have notified me about the fact that you're still using an 1.5 year outdated package, I could reupload a newer tls-1.0.x branch package with the upper bound on cryptocipher. it would take me 1 minute. This is the lazy PvP approach. Anyone can fix old packages if there are still needed, while at the same time not have to play the keep-up-to-date-with-hackage game. Not only this model save *my* time, but it fits better with Haskell's evaluation strategy. -- Vincent