Skip to content

Prepare v2.1.0: changelog, Node.js setup hardening, and a floating major tag - #14

Merged
srtfisher merged 1 commit into
developfrom
feature/v2.1.0-release-prep
Sep 18, 2026
Merged

srtfisher merged 1 commit into
developfrom
feature/v2.1.0-release-prep

Conversation

@srtfisher

Copy link
Copy Markdown
Member

Summary

Release prep for v2.1.0, which packages the pull request reuse work from #13 along with fixes for the failure in this mantle run.

  • Add a retroactive CHANGELOG.md covering every release from 1.0.0 through 2.1.0, and replace the inline changelog in README.md with a link to it.
  • Resolve the node-version input through a new resolve-node-version.sh so a bare lts, lts/, or lts/latest becomes lts/* with a warning instead of failing setup-node.
  • Skip the Node.js setup entirely when upgrade-npm-dependencies is "false", so workflows that only bump the Tested up to header have no dependency on actions/setup-node at all.
  • Upgrade actions/setup-node from v3 to v7, with package-manager-cache: false.
  • Add a Update Major Version Tag workflow so the v2 tag repoints at each published stable release.

What actually broke in that mantle run

Worth stating plainly, because it is not what the error message suggests. mantle's workflow does not pass node-version at all — it pins alleyinteractive/action-update-wordpress-plugin@v2.0.0, and lts is that version's own default. v2.0.1 already fixed the default to lts/*, so the real root cause is the pin, not a missing feature.

That means three separate things have to be true for this class of failure to stop recurring, and this PR covers the first two:

  1. The action tolerates the bad value. lts is still what the v2.0.0 README tells people to write, so anyone who copied that example hits the same wall even on a current release. The action now rewrites it and logs a warning rather than failing.
  2. @v2 consumers get fixes automatically. The v2 release description already says "A pointer to the latest release in the 2.x.x version," but the tag has been stale at v2.0.0 since April 2025. The new workflow keeps it current on every published stable release.
  3. mantle repins to @v2. That is a change in the mantle repo, not this one. Happy to open it separately.

The other failure in that same log

The run also emitted Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v3, actions/setup-node@v3. That is a warning today and a hard failure once GitHub finishes the removal, so actions/setup-node moves from v3 to v7 here.

Two consequences of that jump are worth reviewing:

  • package-manager-cache: false is deliberate. setup-node v5 began caching automatically when package.json declares a packageManager field. Left on, that would reintroduce exactly the npm ci failure fixed back in 1.0.2 for plugins without a package-lock.json. Disabling it preserves the existing behavior.
  • setup-node v5+ requires an Actions runner on 2.327.1 or later. Every GitHub-hosted runner satisfies this; a self-hosted runner might not. This is documented in README.md and the changelog entry.

Making Node.js optional

Per discussion on this branch, the resolve-node-version and setup-node steps are now both gated on inputs.upgrade-npm-dependencies != 'false'. The action only needs Node.js to run npm ci and wp-scripts packages-update, so a workflow that just bumps the Tested up to header now touches no Node.js tooling whatsoever and cannot fail on a version string. This does not help mantle specifically, since mantle passes upgrade-npm-dependencies: "true", but it removes the failure mode for everyone who does not need the npm work.

On the major version tag

The workflow triggers on release: published, skips prereleases and any tag that is not vX.Y.Z, derives the major from the tag, and force-pushes it as an annotated tag. One thing to be aware of: there is an existing GitHub release named v2, and force-moving the tag will make that release point at the new commit. That is the behavior its description asks for, but the release will look like it changed. Say the word if you would rather delete the v2 release and keep only the tag.

Testing

  • ./tests/check-upgrade.sh — 14 tests, all passing
  • ./tests/resolve-node-version.sh — 18 new tests, all passing, covering lts, LTS, lts/, lts/latest, surrounding whitespace, empty input, and pass-through of lts/*, lts/jod, 20, 20.11.1, and latest
  • shellcheck across check-upgrade.sh, resolve-node-version.sh, both test suites, and every stub — clean
  • YAML parsing for action.yml and both workflow files

Both suites now run in the existing CI workflow, whose actions/checkout also moves from v3 to v5.

Follow-up after merge

Publishing the v2.1.0 release will exercise the new workflow and move v2 to it. The very first move still has to be done by hand, since the workflow does not exist on the tag being released — I can run that force-push once you publish, or you can.

Add a retroactive CHANGELOG.md covering every release and move the
changelog out of README.md.

Resolve the node-version input through resolve-node-version.sh so a
bare 'lts', 'lts/' or 'lts/latest' becomes 'lts/*' instead of failing
setup-node, skip the Node.js setup entirely when npm dependencies are
not being upgraded, and upgrade actions/setup-node from v3 to v7 with
package-manager-cache disabled.

Add a workflow that repoints the major version tag at each published
stable release so @v2 resolves to the newest 2.x release.

@mogmarsh mogmarsh left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

MAJOR_TAG="${RELEASE_TAG%%.*}"

git config user.name 'github-actions[bot]'
git config user.email '41898282+github-actions[bot]@users.noreply.github.com'

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be hard coded?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eh it'll be fine I guess

@srtfisher
srtfisher merged commit 14eb0f0 into develop Sep 18, 2026
1 check passed
@srtfisher
srtfisher deleted the feature/v2.1.0-release-prep branch September 18, 2026 14:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants