On Mon, Sep 1, 2014 at 12:47 AM, Gregory Collins <greg@gregorycollins.net> wrote:

On Thu, Aug 28, 2014 at 1:31 PM, Thomas DuBuisson <thomas.dubuisson@gmail.com> wrote:

I fully support directing users to getAddrInfo. My comment boils down
to: let's remove broken functions instead of making them easier to use
and less consistent with the rest of the API.

Only if we run a deprecation cycle for at least one major version of network. Just removing a function breaks code for no reason and is user-hostile. It's important to give end users a warning that the function is going away and some time (12 months or more IMO) to fix their code, especially for packages that belong to the platform.

Why bother? Nobody ever does this now, so there's no good reason to start. It only wastes a little bit of end-use time, all they have to do is dig through docs and/or commit messages (or maybe a changelog message, if someone can be bothered to write one) to see if there's a useful replacement mentioned.

Seriously, I'm strongly in favor of both removing broken-ness and deprecation cycles. Every time we update our library stack I have to go through this, and every time I run across 4 or 5 libraries (minimum) with functions disappearing out from under us. Even top-20, supposedly well-maintained packages are guilty.

John L.