Gearing up (again) for the next release: 2014.2.0.0

[Vincent Hanquez]

On 2014-04-09 13:46, Gregory Collins wrote:
>
> On Wed, Apr 9, 2014 at 2:19 PM, Vincent Hanquez <tab at snarc.org 
> <mailto: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
>

[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