Request: new `v2` tag of this action (that includes the `node20` upgrade)

[DilumAluthge]

Would it be possible to get a new v2 tag of this action that includes https://github.com/pyTooling/Actions/pull/76?

IIUC, in the GitHub Actions ecosystem, this kind of change (upgrading from node16 to node20) is considered a breaking change, which is why I believe the new release should be v2.

Some examples of official actions that made a breaking release (bumped the major version number) when they upgraded from node16 to node20:

1. actions/checkout went from v3 to v4: https://github.com/actions/checkout/releases/tag/v4.0.0
2. actions/cache went from v3 to v4: https://github.com/actions/cache/releases/tag/v4.0.0

[Paebbels]

Changing a dependency (Node.js) does not require a new major version. The behavior of pyTooling/Actions has not changed, nor the API. pyTooling/Actions has bumped its version from v1.0.0 to v1.0.1 for release branch r1.

Please also note, GitHub Actions doesn't support proper tagging nor dependency management, but only simple branch names like r0 and r1.

---

If the GitHub Actions ecosystems is usually bumping revisions for such an unimportant change, I recommend studying "semantic versioning".

[giordano]

Changing a dependency (Node.js) does not require a new major version.

That breaks self-hosted runners which currently runs on systems which only have Node.js 16. This is just one example of an action which bumped the major version to signal the possible breakage when upgrading the required Nodejs version: https://github.com/actions/cache/pull/1284

[bryan-bar]

Changing a dependency (Node.js) does not require a new major version.

That breaks self-hosted runners which currently runs on systems which only have Node.js 16. This is just one example of an action which bumped the major version to signal the possible breakage when upgrading the required Nodejs version: actions/cache#1284

Could this be a variable, so it is configurable at run-time? I understand the thought around this but it also puts more load on the maintainer overtime and I see that it was simple nodejs16 -> node20 change. Today its 2 versions maintained but it can quickly turn into 3+ versions for other tools and dependencies.

It doesn't help when the github actions maintainers decide suddenly everyone needs to upgrade so self-hosted and github-hosted are then out of sync. Github actions can definitely feel like reinventing the wheel and then it is made worse by favoring nodejs for all features over other systems languages/interpreters.

[Paebbels]

Node.js was end-of-life in September 2023. This change was added in March 2024, so 6 months after Node.js 16 was "dead". Please see the release schedule of Node.js: https://github.com/nodejs/release#release-schedule or images below.

I'm not in control of Microsofts (GitHubs) action updates and that they delayed the version upgrade in their actions until the last days of lifetime.

Active Versions	End-of Life Versions

---

That breaks self-hosted runners which currently runs on systems which only have Node.js 16.

One just needs to maintain self-hosted runners and keep them up-to-date. People running self-hostet either care for security or operation costs. If it's the first, one should not run such old out-dated software (runners, Node.js, etc.) and at second, why are these runners allowed to fetch an unverified action from GitHub?

As said before, the version increment of used actions was and will be documented as well as pyTooling/Actions' version will be incremented. So users are free to pin their used action to a specific version. There will be no major version increment unless pyTooling/Actions itself has a breaking change.

---

It doesn't help when the github actions maintainers decide suddenly everyone needs to upgrade [...]

For reused components, the component providers will always decide for them self to update and component users must adjust. This is how software (and dependencies) works. If one can't agree on that fact, one is always free to stick to the old version! That's why versions are tagged.

[...] so self-hosted and github-hosted are then out of sync.

It's up to GitHub to have a strategy on that topic. I haven't seen such issues with GitLab.

[bryan-bar]

It doesn't help when the github actions maintainers decide suddenly everyone needs to upgrade [...]

For reused components, the component providers will always decide for them self to update and component users must adjust. This is how software (and dependencies) works. If one can't agree on that fact, one is always free to stick to the old version! That's why versions are tagged.

[...] so self-hosted and github-hosted are then out of sync.

It's up to GitHub to have a strategy on that topic. I haven't seen such issues with GitLab.

I agree with all your points including your versioning, I was more ranting about Microsoft's GitHub action maintainers and their platform when I said "GitHub action maintainers", not you. I should have been more clear.

[Paebbels]

@bryan-bar :)