[Haskell-cafe] ANN: network 3.0.0.0

[Evan Borden]

Niklas,

I appreciate and empathize with your concerns. Care was taken to utilize a
deprecation cycle for as much of the API as possible, as we knew that these
changes would cause churn in the ecosystem. As you noted, some breaking
changes were not communicated early through these means. Instead we decided
to mark an epoch change in network to signal that there would be
significant breakage. This follows conventions established by Ed Kmett,
which are documented here https://pvp.haskell.org/faq/. I'm not sure a
specific convention exists for a situation where the type of a function
will change in a future version. I'd love to hear ideas.

Thank you very much for the feedback. Constructive criticism is necessary
to improve our handling of these issues and is always welcome with open
arms.

On Sat, Jan 19, 2019 at 9:56 AM Niklas Hambüchen <mail at nh2.me> wrote:

> Hey Evan,
>
> it's great that work is being done on network, that is very appreciated.
> I do find one thing problematic though:
>
> Why do breaking type changes like `fdSocket` and `mkSocket` not go through
> a deprecation cycle?
>
> It's a best-practice to not break types of fundamental packages unless
> absolutely necessary.
> In this case it seems like these functions could have been deprecated,
> kept forever, and new functions with the improved types could have been
> added.
> This would avoid breakage for network's many users.
>
> Given that rest of the changelog in which deprecations are mentioned, it
> seems `network` contributers generall understand that and agree on that.
> Why was the deprecation approach not chosen for these functions?
>
> What in general is network's decision process for deprecation vs breaking
> change? Was any analysis performed that showed that only the fewest of
> network's 926 Hackage dependencies use these functions? Or should we expect
> major ecosystem breakages?
>
> Also interesting is that in
> https://github.com/haskell/network/commit/d69c3072071859a28a442ff713e90f8499882d21
> `fdSocket` was deprecated, but that deprecation was about a slightly
> different change and never made it into any Hackage release so users never
> saw an advance hint that `fdSocket` would soon be changed.
>
> Personally, it bugs me out that we can't get deprecations right in
> Haskell, when other ecosystems have understood and successfully executed
> the "deprecate and make better functions" approach for a very long time.
> But I'd be happy to hear why I'm wrong and this approach couldn't be used
> here.
>
> Niklas
>


-- 
--
Evan Borden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190119/217234d6/attachment.html>