sys: Remove after 3 years of deprecation #182
Conversation
|
Everyone: thoughts on this? Anecdotal: I still see code from time to time that uses the sys module and that would break without prior warning. That makes outright removal unacceptable, IMO. The sys module was changed to throw an exception in v0.7 and v0.8 but that resulted in nodejs/node-v0.x-archive#3577 and a subsequent revert in v0.8.1. I'm going to bring this up at the next TC meeting. If we are going to go ahead, then the module should log a warning first for some time, to give people a chance to upgrade their code and dependencies. |
Burn it with fire:
I have concerns about people screaming "hey, io.js is not compatible with node.js", but other than that, it'd be nice to finally deprecate sys. |
|
What has changed from the last time we tried to deprecate it? Also, what is the cost of having the link to sys? |
|
I really want you all to formalize a set of deprecation guidelines you will try to follow. |
|
From today's TC meeting: flat out removing is not the way to go but making @geek If you make the requested changes, I'll land this. Grep lib/ for util.deprecate for examples. |
|
@bnoordhuis and @rvagg at what point after a function/module is hard deprecated will it be deleted? |
|
@geek Probably never. It's not broken and it's not a maintenance burden. Even a deprecation message is somewhat debatable but deprecation messages can be disabled if you really must; at least it shoos people away from using 'sys' in new code. |
|
@bnoordhuis is this specific to |
|
@vkurchatkin Just for sys. The consensus was that things that are broken or a maintenance hassle can be phased out given enough time. For the other kind of deprecated (discouraged but not defective), it can stay in perpetuity. |
|
@bnoordhuis thanks for the response. Your last comment cleared up what I was getting at... what the policy is for deleting deprecated items. I strongly dislike dead code, particularly because it does add cost to a project. I'll update the PR as outlined above. |
|
@geek will you be updating this or shal we open it up for others to contribute by submitting a new PR? |
|
@rvagg I'll do it now... do you want it in the v1 branch? |
|
Closing in favor of #309 |
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.
Related PR on node.js: nodejs/node-v0.x-archive#8880
Larger issue that I want to see addressed: A formal deprecation policy.
My proposal is that any deprecated code get deleted/obsoleted in the next major version. If this is the case, we can delete a lot of other deprecated code that's rotting away :)