Node16 -> node20 upgrade should maybe have been a major version bump?

[TrueBrain]

This is more informational, and I just wanted to let you know:

For most Rust-based workflows, we use your action, as it really helps out with setup etc. So I am really grateful for the work you put in here, and keeping it maintained. So first off: thank you!

Sadly, 2 days ago you made a new patch version (2.7.2) which most likely should have been a new major version (like 3.0.0). As most other actions at least did (actions/checkout and family). A node16 -> node20 upgrade is for most people not a small thing, and actually causes breakage of many workflows (as it does for us currently). Most actions left behind an older major version which was still node16 compatible, and went on with a new major version which was node20 compatible. This gives the opportunity to the user using the action when to upgrade.

There are some downsides to that approach, as everyone that wants to use node20 will need to bump their workflow to use the new major (assuming people follow @v2 in their workflows), but on the other hand it maintains workflows that depend on node16.

Sadly for us, we currently have no possibility to upgrade to node20 (we also don't run in the GitHub Runner itself). So for now I will be pinning our action to @v2.7.0. But I just wanted to let you know that this was kinda unexpected, as I can imagine it is not all that clear that a node upgrade is kinda a major thing :)

So again, just informational. As honestly, we really should have upgraded tot node20 already :P Tnx again for this action, I am very happy it exists!

[Swatinem]

Hi there!
Sorry for the inconvenience. Indeed I kinda got used to toolchain updates (MSRV) being bumped regularly without problems.
Now that you mention it, I remember that in the node ecosystem these things are treated a bit more seriously. The problem is also that the code itself should run just fine in older node versions, its rather the GHA metadata that bumped up the version, which is a bit unfortunate.

Its also unfortunate that github started spewing warning by default as reported in #174, so its sad that there is no way to both satisfy backwards compatibility for the users who selfhost, as well as keep things running smoothly without intervention for the majority of people who just use the github hosted runners. :-(

[cretz]

👍 Some jobs also use a separate container to build with older glibc (e.g. we use quay.io/pypa/manylinux2014_x86_64), but now that newer node is used which requires newer glibc, running rust cache under that container gives:

/usr/bin/docker exec  b54089c19a9932c4c99692ecbb53e40d89835df75cfc6bd1a3b4c5d671cd9dad sh -c "cat /etc/*release | grep ^ID"
/__e/node20/bin/node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /__e/node20/bin/node)