-
Notifications
You must be signed in to change notification settings - Fork 143
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
doc: propose revising the downloads page #598
Conversation
I think I generally agree with that. There are issues with external tools, though. For example Chocolatey takes time to update. |
Main problem being: on the website we show the command |
FTR Chocolatey used to scrape https://nodejs.org/en/download and https://nodejs.org/en/download/current, which broke when the website redesign went live. chocolatey-community/chocolatey-packages#2453 was merged yesterday. |
OH! |
I assume then that this is a self-fulfilling prophecy? It should not work out of the box? |
If they need a tool to scrape the updated data generated by the build team we have one maintained by this groups (the PMWG) here: https://github.com/pkgjs/nv I agree this is an issue and any tools we recommend on the page should have a fast and reliable support policy. Do we need to add language clarifying the requirements to be included on the download page maybe? |
I did point the person asking about this to that 🙂: https://github.com/orgs/nodejs/discussions/52407#discussioncomment-9038845 |
Just some short input from me (who repaired the choco script for nodejs):
|
Just to be particular about this, the reason we thought it was a good idea for the node project to own a tool for this job was so the build or release group could change the location and have a clear and known place to help the community keep up. I don't know anything about the choco package or the maintainer, so I trust you made a good decision here, but IMO the "it shouldn't move" is very near to "it shouldnt change" which is equally problematic from a contract perspective. It is an un-versioned resource, which leads to issues like this. Luckily it is a low change thing so likely not a big deal, but if you can suggest to them that "in order to remain on the download page instructions for the project it is recommended to use their tool for fetching and parsing the data" that would be idea IMO. |
All this discussion of Chocolatey is off-topic, in my opinion. Nothing in this PR mentions Chocolatey or any particular package or version manager. This proposal is just about the idea of revising the downloads page toward a new general goal, not the particulars of what the new draft should be. I think we can get into those details in the PR that actually does the rewrite, assuming that this proposal is approved. |
Yeah, I do think that we should address at some point (maybe not this point) what the qualities we require things to have to be included in those instructions for the future. But for now I agree it is likely not required to land this PR and then do the website changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I agree that the discussion of specific tools is off topic for this PR. I think if we agree on the The approach does not pre-suppose any solution as the target end state. It There will likely be challenges with existing tools which is what are likley to be documented in the recommended first step of updating the web site, but even if they are imperfect they might be a reasonable step towards the longer term goal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM?
Following up #597, this is a proposal for a first step toward achieving those goals.
cc @nodejs/package-maintenance @nodejs/nodejs-website @nodejs/tsc