ci: migrate release-please off its archived action to googleapis/release-please-action@v5

[NickJosevski]

Must merge before #13. See Merge order below. Supersedes the Dependabot PR #17 — see the warning at the end.

Why

google-github-actions/release-please-action is archived. The action moved to googleapis/release-please-action, now v5. Our whole release path currently runs on the unmaintained one.

Why this isn't a pin bump

v4 made two breaking changes that both affect us:

1. command was removed in favour of skip toggles:

-          command: github-release
+          skip-github-pull-request: true

-          command: release-pr
+          skip-github-release: true

2. Most configuration inputs were removed in favour of a config file — including release-type and bump-minor-pre-major. Those move into release-please-config.json, with .release-please-manifest.json tracking the current version:

{
  "bump-minor-pre-major": true,
  "packages": { ".": { "release-type": "simple" } }
}

bump-minor-pre-major is carried over deliberately. #15 sets it as a v3 action input so the release stays 0.2.0 instead of 1.0.0. In v5 that input does not exist, so without this config file the setting would be silently ignored and the next breaking change would jump to 1.0.0.

The outputs the tag-maintenance step reads — release_created, major, minor — are unchanged in v5.

⚠️ This supersedes #17, which would break the release workflow

Dependabot opened #17 bumping google-github-actions/release-please-action v3 → v4 while leaving command: github-release and command: release-pr in place. v4 removed command, so merging #17 breaks release-please.yml.

Its three checks pass, which is misleading: tests.yml never exercises release-please.yml, so nothing in CI can catch it. #17 also stays on the archived repo, so it's a dead end regardless. Recommend closing #17 in favour of this PR.

⚠️ Merge order

.release-please-manifest.json pins the current released version, 0.1.1. That is correct only until 0.2.0 ships.

1. fix: keep breaking changes inside 0.x instead of releasing 1.0.0 #15 — keeps the release at 0.2.0 rather than 1.0.0
2. ci: stop Update README corrupting the plugin version lines (unblocks the 1.0.0 release) #14 — unblocks chore(main): release 1.0.0 #13's failing Lint
3. this PR
4. chore(main): release 1.0.0 #13 — the 0.2.0 release

If 0.2.0 is released before this merges, update .release-please-manifest.json to 0.2.0 first, or release-please will think 0.1.1 is current and may re-propose an already-released version.

What can't be verified before merge

release-please.yml only runs on push to main, so this cannot be exercised on a branch. The JSON validates and the workflow parses, but the first real run is the merge — worth merging alone and watching that run.

Rebased 2026-08-22 after #11 merged, dropping the pin-bump commit it was stacked on.

🤖 Generated with Claude Code