<div dir="ltr">> Doesn't quickly adding a deprecation warning break building any of those 1000+ packages with -Werror?<div><br></div><div>It appears that <a href="https://github.com/haskell/pvp/issues/12">https://github.com/haskell/pvp/issues/12</a> is close to being resolved[1], and as hvr mentioned Hackage already prevents packages with -Werror from being uploaded, so this shouldn't be an issue for packages already uploaded. But yes, if someone is using unordered-containers and building locally with -Werror then the build would fail.</div><div><br></div><div>That being said, if the plan is to deprecate it then I don't think there's a better way than marking it DEPRECATED. We could go with a "soft" deprecation--remove function comments and replace with "This function is deprecated, use findWithDefault" and make some announcements--but I doubt many people would act on that so it would just be kicking the can down the road.<div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"></span><span style="font-size:12.8px">> </span><span style="font-size:12.8px">I'd support adding the new function, but am very reluctant to force any quick changes.</span><br style="font-size:12.8px"><span style="font-size:12.8px"><br>Glad to hear! It would be nice if there was a way of getting information about how often this particular function was used so we could get a better estimate of how many packages would truly be affected. And I completely agreed that we should do everything we can to not break people's builds, but hopefully not at the expense of improving APIs.</span></div><div><span style="font-size:12.8px"><br>[1] <a href="https://github.com/haskell/pvp/pull/18">https://github.com/haskell/pvp/pull/18</a></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 24, 2018 at 3:25 PM,  <span dir="ltr"><<a href="mailto:amindfv@gmail.com" target="_blank">amindfv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Doesn't quickly adding a deprecation warning break building any of those 1000+ packages with -Werror?<br>
<br>
I'd support adding the new function, but am very reluctant to force any quick changes.<br>
<br>
Tom<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> El 24 ene 2018, a las 09:25, Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de">andreas.abel@ifi.lmu.de</a>> escribió:<br>
><br>
> > I'd say 1 year is too short. There is no need to remove the function<br>
> > quickly. I'd vote for adding a deprecation warning soon, but then keep<br>
> > the function until the next larger API overhaul or say, for five years<br>
> > or a decade.<br>
><br>
> +1.<br>
><br>
> Yes.<br>
><br>
>> On 24.01.2018 08:11, Henning Thielemann wrote:<br>
>>> On Tue, 23 Jan 2018, Matt Renaud wrote:<br>
>>> Cons:<br>
>>> -----<br>
>>><br>
>>> - API change requires users to update their code<br>
>>>   + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days)<br>
>> A better measure are certainly the reverse package dependencies:<br>
>>    <a href="https://www.stackage.org/package/unordered-containers" rel="noreferrer" target="_blank">https://www.stackage.org/<wbr>package/unordered-containers</a><br>
>> There are almost 1000 packages that import unordered-containers, still quite a lot!<br>
>>> Migration - Option 1:<br>
>>> ---------------------<br>
>>><br>
>>> - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit<br>
>>> thread, etc.)<br>
>>> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function<br>
>>> - Code can be updated by find and replace: s/lookupDefault/<wbr>findWithDefault/<br>
>>> - lookupDefault with deprecation notice remains for 1 year (subject to change)<br>
>>> - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major<br>
>>> version bump due to breaking change)<br>
>> I'd say 1 year is too short. There is no need to remove the function quickly. I'd vote for adding a deprecation warning soon, but then keep the function until the next larger API overhaul or say, for five years or a decade.<br>
>> ______________________________<wbr>_________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
><br>
><br>
> --<br>
> Andreas Abel  <><      Du bist der geliebte Mensch.<br>
><br>
> Department of Computer Science and Engineering<br>
> Chalmers and Gothenburg University, Sweden<br>
><br>
> <a href="mailto:andreas.abel@gu.se">andreas.abel@gu.se</a><br>
> <a href="http://www.cse.chalmers.se/~abela/" rel="noreferrer" target="_blank">http://www.cse.chalmers.se/~<wbr>abela/</a><br>
> ______________________________<wbr>_________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>