<div dir="ltr"><div dir="ltr">Niklas,<div><br></div><div>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 <a href="https://pvp.haskell.org/faq/">https://pvp.haskell.org/faq/</a>. 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.</div><div><br></div><div>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.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 19, 2019 at 9:56 AM Niklas Hambüchen <<a href="mailto:mail@nh2.me">mail@nh2.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Evan,<br>
<br>
it's great that work is being done on network, that is very appreciated.<br>
I do find one thing problematic though:<br>
<br>
Why do breaking type changes like `fdSocket` and `mkSocket` not go through a deprecation cycle?<br>
<br>
It's a best-practice to not break types of fundamental packages unless absolutely necessary.<br>
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.<br>
This would avoid breakage for network's many users.<br>
<br>
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?<br>
<br>
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?<br>
<br>
Also interesting is that in <a href="https://github.com/haskell/network/commit/d69c3072071859a28a442ff713e90f8499882d21" rel="noreferrer" target="_blank">https://github.com/haskell/network/commit/d69c3072071859a28a442ff713e90f8499882d21</a> `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.<br>
<br>
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.<br>
<br>
Niklas<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">--<div>Evan Borden</div></div></div>