nodejs / package-maintenance

Repository for work for discussion of helping with maintenance of key packages in the ecosystem.
Other
404 stars 142 forks source link

doc: propose revising the downloads page #598

Closed GeoffreyBooth closed 2 months ago

GeoffreyBooth commented 2 months ago

Following up #597, this is a proposal for a first step toward achieving those goals.

cc @nodejs/package-maintenance @nodejs/nodejs-website @nodejs/tsc

targos commented 2 months ago

I think I generally agree with that. There are issues with external tools, though. For example Chocolatey takes time to update. Versions 22.0.0 and 21.7.3 were only added yesterday, and version 21.7.2 was apparently skipped: https://community.chocolatey.org/packages/nodejs#versionhistory CleanShot 2024-04-26 at 11 16 08

targos commented 2 months ago

Main problem being: on the website we show the command choco install nodejs --version="22.0.0". This command is guaranteed to fail until the chocolatey distribution is updated.

richardlau commented 2 months ago

For example Chocolatey takes time to update. Versions 22.0.0 and 21.7.3 were only added yesterday, and version 21.7.2 was apparently skipped

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. https://github.com/chocolatey-community/chocolatey-packages/pull/2453 was merged yesterday.

ovflowd commented 2 months ago

For example Chocolatey takes time to update. Versions 22.0.0 and 21.7.3 were only added yesterday, and version 21.7.2 was apparently skipped

FTR Chocolatey used to scrape nodejs.org/en/download and nodejs.org/en/download/current, which broke when the website redesign went live. chocolatey-community/chocolatey-packages#2453 was merged yesterday.

OH!

ovflowd commented 2 months ago

I assume then that this is a self-fulfilling prophecy? It should not work out of the box?

wesleytodd commented 2 months ago

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?

richardlau commented 2 months ago

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 did point the person asking about this to that 🙂: https://github.com/orgs/nodejs/discussions/52407#discussioncomment-9038845

michha commented 2 months ago

Just some short input from me (who repaired the choco script for nodejs):

wesleytodd commented 2 months ago

the current solution should be pretty stable as long as the location of json files isnt changed

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.

GeoffreyBooth commented 2 months ago

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.

wesleytodd commented 2 months ago

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.

mhdawson commented 2 months ago

I agree that the discussion of specific tools is off topic for this PR.

I think if we agree on the approach then the specific issues and problems with what we might recommend can be handled in the PRs and discussion around what to recommend.

The approach does not pre-suppose any solution as the target end state. It might be to use existing tools, it might be to create a new tool that is cross platoform.

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.