> Doesn't quickly adding a deprecation warning break building any of those 1000+ packages with -Werror?

It appears that https://github.com/haskell/pvp/issues/12 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.

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.

> I'd support adding the new function, but am very reluctant to force any quick changes.

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.

[1] https://github.com/haskell/pvp/pull/18

On Wed, Jan 24, 2018 at 3:25 PM, <amindfv@gmail.com> wrote:
Doesn't quickly adding a deprecation warning break building any of those 1000+ packages with -Werror?

I'd support adding the new function, but am very reluctant to force any quick changes.

Tom


> El 24 ene 2018, a las 09:25, Andreas Abel <andreas.abel@ifi.lmu.de> escribió:
>
> > 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.
>
> +1.
>
> Yes.
>
>> On 24.01.2018 08:11, Henning Thielemann wrote:
>>> On Tue, 23 Jan 2018, Matt Renaud wrote:
>>> Cons:
>>> -----
>>>
>>> - API change requires users to update their code
>>>   + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days)
>> A better measure are certainly the reverse package dependencies:
>>    https://www.stackage.org/package/unordered-containers
>> There are almost 1000 packages that import unordered-containers, still quite a lot!
>>> Migration - Option 1:
>>> ---------------------
>>>
>>> - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit
>>> thread, etc.)
>>> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function
>>> - Code can be updated by find and replace: s/lookupDefault/findWithDefault/
>>> - lookupDefault with deprecation notice remains for 1 year (subject to change)
>>> - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major
>>> version bump due to breaking change)
>> 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.
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel@gu.se
> http://www.cse.chalmers.se/~abela/
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries