add deprecate guidelines doc [draft] #150
Conversation
mcollina
added
the
package-maintenance-agenda
|
I think this might be mixing different concerns. What should a consumer do and what might this team do. Would it make sense to break it out into those 2 sections or possibly 2 doc? |
|
I made some changes with target audience in mind. Please re-review. |
docs/drafts/DEPRECATE-GUIDELINES.md
Outdated
|
|
||
| ## `npm deprecate` command | ||
| Once you've identified a package may be unmaintained, please open an issue for the Node.js package-maintenance working group to check and identify path forward. |
There was a problem hiding this comment.
Is this the right recommendation? I would like to see package-maintenance group to be the last resort (depending on popularity of the package, of course), but I would generally recommend looking for alternatives (are there any tools out there?) and then forking, i.e. dyi?
There was a problem hiding this comment.
Forking is an important ability, but I see that as more of a last resort than asking this group - creating forks further fractures the ecosystem, and doesn't help all of the users who are still using the unmaintained version unwittingly.
There was a problem hiding this comment.
if no one can reach the author then there's really not much anyone could do. I was thinking that the best this group could do is get npm ownership and actively advertise for someone interested in becoming the maintainer, and/or add deprecate message to identify alternative if one exist.
docs/drafts/DEPRECATE-GUIDELINES.md
Outdated
|
|
||
| ## `npm deprecate` command | ||
| Once you've identified a package may be unmaintained, please open an issue for the Node.js package-maintenance working group to check and identify path forward. |
There was a problem hiding this comment.
Forking is an important ability, but I see that as more of a last resort than asking this group - creating forks further fractures the ecosystem, and doesn't help all of the users who are still using the unmaintained version unwittingly.
Co-Authored-By: jchip <jchip@users.noreply.github.com>
Co-Authored-By: jchip <jchip@users.noreply.github.com>
Co-Authored-By: jchip <jchip@users.noreply.github.com>
Co-Authored-By: jchip <jchip@users.noreply.github.com>
Co-Authored-By: jchip <jchip@users.noreply.github.com>
Co-Authored-By: jchip <jchip@users.noreply.github.com>
Co-Authored-By: jchip <jchip@users.noreply.github.com>
|
@jchip are you still interested in getting this PR landed? Otherwise, is there anybody else that would like to help in moving this forward? |
|
@jchip I'd be glad to take this over if you don't have time, no pressure! |
|
@mcollina I addressed the review comments in my last commit and I don't see any further comments. I was hoping for enough approves to move this to be considered for merging. @craftninja Thanks for the offer. I'd like to see if there're anymore comments and see if this PR can get enough approves to be considered merging. I generally have problem attending every other meeting due to me being in PST, but will see if I can get this discussed and merge in next meeting. |
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
|
@ljharb thanks, going through them again. On a side note, I miss them partly due to github has this curious way of reseting the page to the top after you commit each suggested changes, and then you have to scroll down, expand comments, and find back to where you were. Is that just me? Is there a better way? |
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
|
@ljharb that should be all of them. Please review. Thanks. |
|
Only for note. In a following PR, I think it could be worth adding some node args like --throw-deprecation |
|
Looks like this is ready to land. |
No description provided.