-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Missing deprecation information for the package in npm #579
Comments
Deprecation isn’t the same thing as unsupported. |
Thank you for the comment. English is not my first language, so perhaps I'm missing a nuance here. What do you want to communicate with this comment, though? Even if it's not the same thing, do you think that NPM depreciations would be an unsuitable way to communicate lack of support? I don't appreciate useless nitpicking, only useful nitpicking. Edit: |
Deprecation means you actively shouldn’t use a version. Being unsupported doesn’t inherently mean you shouldn’t use that version - it just means if a problem arises you won’t be guaranteed a fix. |
Thanks for the explanation. In any case, I propose using the npm-deprecate tool to inform users of unsupported versions (<7). Since that's obviously one of the things it was meant for. Satisfied? |
Like 40 million people still have semver 6 in their dep trees; that’s a lot of noise that isn’t particularly valuable, especially when the only “problem” is a CVE that in practice never is actually a vulnerability. That deprecation can be used to convey something is unsupported doesn’t mean it’s a good use of it. |
So you don't feel that being informed about unsupported software in your supply chain is valuable - we'll agree to disagree. |
To be clear, I would prefer that Npm/Github/Microsoft kept supporting v5 and V6, but if that's not happening, I would rather have people be aware of this. Hiding problems because they feel unfixable is bad. |
I didn't say that, but since deprecation doesn't programmatically convey "supported" or not, and since virtually no packages use deprecation in this way, that's not a good way to signal that. Being unsupported is not inherently a problem. |
Yes it is. |
Anyway, you have made several valid points @ljharb, thank you for that. Let's hear what the maintainer has to say about this. |
To address the original point made here, we will be releasing fixes for the latest CVE in v5 (ref: #585) and v6 (ref: #591). As for whether to deprecate old versions, there are many many old major versions or our libraries that we do not support, but I don't think I'm going to close this specific issue now, but further thoughts are welcome in the issue I linked above. |
@lukekarrys you may want to adopt the node package maintenance working group's process: https://github.com/pkgjs/support (you can check an example of it in use here: inspect-js/object-inspect@ca20ba3 and inspect-js/object-inspect@e2618d2 ) |
It's great that the issue got resolved by backporting the fix to previous versions and also good to hear that you are taking action to communicate the level of support for the package. Thanks! |
Is there an existing issue for this?
Current Behavior
Based on this comment, you are not supporting any other major version than 7. Please mark all versions prior to 7 as deprecated in the NPM registry, this will increase users' awareness that they are using unsupported software. Based on NPM download statistics, major version 7 only accounts for less than half of downloads in the last seven days. If you are only supporting v7, that's a major issue that needs to be honestly communicated to the users who download deprecated versions 150M+ times every week.
Expected Behavior
No response
Steps To Reproduce
No response
Environment
No response
The text was updated successfully, but these errors were encountered: