A linked PR to update some of the Github workflows.
435
Theoretically, this shouldn't affect any released builds, as I am not changing the node version used for publishing.
The reasoning behind this is EOL software such as -
and Node 16 EOL -
Move from Checkout@v3 to v4 - no advanced features are being used, so updating should be safe. Tested on the build.yml workflow and appears to be okay -
Move from setup-node@v2 to v4 - Same as above.
As for the matrix of Node versions, I have a quick proposal to remove Node 16 and add Node 20.
The reason is that Node 16 is EOL, and the project already specifies Node 20 in the package.json
I'm happy to put in a separate PR, but I want your thoughts.
Node 20 builds successfully -
npm_publish and release_publish can still use node 18 for stability but this would allow a check to ensure future changes work with node 20 for when Node 18 becomes EOL in 2025.
A linked PR to update some of the Github workflows.
435
Theoretically, this shouldn't affect any released builds, as I am not changing the node version used for publishing. The reasoning behind this is EOL software such as -
and Node 16 EOL -
Move from Checkout@v3 to v4 - no advanced features are being used, so updating should be safe. Tested on the build.yml workflow and appears to be okay -
Move from setup-node@v2 to v4 - Same as above.
As for the matrix of Node versions, I have a quick proposal to remove Node 16 and add Node 20. The reason is that Node 16 is EOL, and the project already specifies Node 20 in the package.json I'm happy to put in a separate PR, but I want your thoughts.
Node 20 builds successfully -
npm_publish and release_publish can still use node 18 for stability but this would allow a check to ensure future changes work with node 20 for when Node 18 becomes EOL in 2025.