Introducing breaking changes without bumping major version

[alec-drw]

Introducing breaking changes without bumping major version

[eregon]

I shared my opinion in #539 (comment).
This was also done for the previous node update (12 -> 16) and there was zero reported problem.

IMO it's far more work to update hundreds of thousands workflows to @v2 when none of them actually need that (the API of the action does not change at all), the real fix is to install node20, and that's the responsibility of whoever maintains the runner. Only them can do that.

I will not do v2, because I do not have time to maintain multiple branches and then users on v1 (i.e. all current users) would not get newer Ruby versions, while they didn't do anything wrong.

They finally added it via an environment variable ACTIONS_RUNNER_FORCED_INTERNAL_NODE_VERSION to support both cases, see actions/runner#2844

That seems a reasonable solution if node20 cannot easily be installed on your self-hosted runners for some reason.
Of course it's not actually tested and so not officially supported but is very likely to work.
Indeed this action doesn't really care about which node version it uses, but it should also not cause deprecation warnings like in #539 (comment).

[eregon]

Some more thoughts on this:

• Bumping to node20 is a seamless change for workflows using GitHub-hosted runners. In fact it even fixes a warning.
• Self-hosted runners can never be supported fully, because they can't be tested by this action and every self-hosted runner is potentially different. The docs in https://github.com/ruby/setup-ruby/blob/master/README.md#using-self-hosted-runners says: This action might work with self-hosted runners if the Runner Image is very similar to the ones used by GitHub runners. The same node version is part of that, we could add it to make it more explicit.
• It's unfortunate that action.yml cannot specify a version constraint like node >= 12, <= 20 (AFAIK), and that one cannot test an action easily with different node versions on GitHub-hosted runners (AFAIK). I would support a request to GitHub to make this possible, and it would be a proper solution to this issue.
• ACTIONS_RUNNER_FORCED_INTERNAL_NODE_VERSION is probably the best workaround until then for self-hosted runners, if they cannot reuse https://github.com/actions/runner-images to automatically keep their runner images up-to-date.
• I could add a node16 tag or so, but not sure if it helps anything?
• Semantic versioning has no good solution when it comes to changes like this. A major version bump is e.g. a bad deal for workflows using GitHub-hosted runners, these users would want to still use the latest release with a compatible API (inputs, etc) like 1.x. Maybe a 4th digit or so would make sense, like APIcompatibility.dependenciesVersion.newFeature.bugFix or so.