[BUG] Missing deprecation information for the package in npm
Closed this issue · 13 comments
Is there an existing issue for this?
- I have searched the existing issues
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
Deprecation isn’t the same thing as unsupported.
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:
I would also like to point you to the documentation for npm-deprecate, which uses a message about an unsupported version as one of the examples. So I would say that NPM deprecation warnings are an appropriate tool for this use.
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.
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.
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.
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 npm-deprecate is the right tool for that. Previously, I created an issue in our statusboard for how we might define our support for our open source projects: npm/statusboard#613 and I'll add to it a note about specifying support for old versions. My current thinking is that we'll create a SUPPORT.md document in each repo detailing the level of support the latest version gets, as well as any older versions.
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!