fix: restore changesets/action v1 and split into v1/v2 lines

[unional]

Same defect, same fix as repobuddy/.github#45. Found while fixing that one — these two repos share these workflows.

What is broken

Renovate bumped changesets/action v1 → v2 (7c50b05) and Mergify auto-merged it. That major renamed every input and added a hard check on the consumer's @changesets/cli major.

All seven changesets workflows here are on @v2.0.0 while still passing the v1 input names, so six of them abort outright:

Error: The following inputs have been renamed:
- "publish" -> "publish-script"
- "version" -> "version-script"
- "commit"  -> "commit-mesage"

and all seven fail for consumers on CLI v2:

This version of the Changesets action is designed to work with Changesets CLI v3.
Changesets CLI v2 is not supported; use Changesets action v1 instead.

Every consumer pins @main, so every changesets release path in the org is broken right now. Most repos have not noticed because they have not released since.

Why two lines, not one fix

changesets/action and @changesets/cli are strictly paired, and the action enforces it:

action	works with	inputs
v1	CLI v2	version, publish, commit
v2	CLI v3	version-script, publish-script, commit-message

Consumers are split across both majors, so no single workflow serves them:

@changesets/cli	Repos	Pin
v3	monorepo-template ^3.0.0, stable-context ^3.0.0	@v2
v2	assertron ^2.26.2, async-fp ^2.26.0, iso-error 2.31.1, jest-watch-repeat ^2.25.2, never-fail ^2.25.0, path-equal ^2.26.0, satisfier ^2.26.2, standard-log ^2.25.0, tersify ^2.29.8, type-plus ^2.29.8, unpartial ^2.25.0	@v1

(eslint-plugin-harmony uses the workflow but declares no @changesets/cli dependency at all — worth a look separately; it belongs on @v1 either way.)

What this PR does

main becomes the v1 line: reverts all seven workflows to changesets/action@v1. That alone unbreaks the eleven CLI-v2 consumers, who stay correct on @main in the meantime.

Adds a README section documenting the scheme, the pin-by-CLI-major rule, and the release procedure.

The v2 line is on the pushed v2.x branch: all seven on @v2.0.0 with renamed inputs. yarn2-library-release.yml keeps its commented-out with: block — no live inputs to rename there.

After merge

git checkout main && git pull
git tag -a v1.0.0 -m "v1.0.0" && git push origin v1.0.0
gh release create v1.0.0 --generate-notes
git tag -f v1 v1.0.0 && git push -f origin v1

git checkout v2.x   # rebase onto main first if this PR is squashed
git tag -a v2.0.0 -m "v2.0.0" && git push origin v2.0.0
gh release create v2.0.0 --generate-notes
git tag -f v2 v2.0.0 && git push -f origin v2

Then monorepo-template and stable-context move to @v2 — they are the two that stay broken until they do. The other eleven can move to @v1 at leisure.

Not fixed here

Mergify's head~=^(?!major-) guard is meant to hold majors back, but Renovate does not prefix these branches with major-, so it never matches and majors merge unreviewed. That is how this landed. Separate defect.

[changeset-bot]

⚠️ No Changeset found

Latest commit: d00f460

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request