ci: pin eds-core-react-next beta releases to a fixed 3.0.0-beta.N series

[pomfrida]

Why

The /next (EDS 2.0) beta channel rolled its version base on every feat(next) (2.6.0-beta.0 → 2.7.0-beta.1 → 2.8.0-beta.1), presenting the betas as previews of stable 2.x minors. EDS 2.0 graduates as 3.0.0, so betas should be a fixed 3.0.0-beta.N series where only the counter climbs.

Closes #5141

What

Adds "versioning": "prerelease" + "prerelease": true to the eds-core-react-next entry in release-please-config.json — the same configuration eds-tokens already uses, validated by the 2026-07-20 release (eds-tokens 3.0.0-beta.0 → 3.0.0-beta.1 from a feat without rolling the base).

With the base at 3.0.0-beta.N (minor and patch both 0), release-please's prerelease versioning strategy bumps only the beta counter for every commit type:

Commit	Next version
fix(next):	3.0.0-beta.N+1
feat(next):	3.0.0-beta.N+1
fix(next)!: / feat(next)!:	3.0.0-beta.N+1 + BREAKING CHANGES changelog section

At graduation, flipping "prerelease": false (or a Release-As: 3.0.0 footer) emits stable 3.0.0.

Deviation from the issue

#5141 prescribed custom version automation in publish_core_react.yaml, on the premise that release-please cannot pin the base. Verified against release-please v17 source (src/versioning-strategies/prerelease.ts, bundled as 17.6.0 in release-please-action@v5): the premise is outdated — versioning: "prerelease" pins the base natively as long as minor/patch are 0. No workflow changes are needed: the publish workflow reads version.txt, which release-please owns, and .github/release-please-manifest.json + version.txt are already at 3.0.0-beta.1 after the 2026-07-20 release, so no reset/bootstrap step is needed either.

Docs updated accordingly (release-please-config.md, BETA_RELEASE_GUIDE.md), including replacing the "no ! in beta commits" rule: ! is now safe (the base cannot roll) and preferred, since it produces a "⚠ BREAKING CHANGES" section for consumers.

Verification

• release-please release-pr --dry-run against this branch: config parses, strategy accepted (result posted in comments).
• Real end-to-end proof: the next /next merge to main must produce a release PR with eds-core-react-next: 3.0.0-beta.2.

[pomfrida]

Dry-run verification (release-please@17.6.0 release-pr --dry-run --target-branch=ci/pin-next-beta-3.0.0):

• Config parses with the new versioning: "prerelease" + prerelease: true options; all 7 package entries built without errors.
• The packages/eds-core-react/src/components/next entry correctly resolves its latest release as eds-core-react-next@v3.0.0-beta.1 and finds 0 releasable commits since — so no bump is proposed yet, as expected.
• Would open 0 pull requests overall.

End-to-end proof lands with the next /next merge to main: the release PR must propose eds-core-react-next: 3.0.0-beta.2.

[pomfrida]

@claude review

[claude]

Claude finished @pomfrida's task in 3m 37s —— View job

---

Review: PR #5190 — pin /next betas to 3.0.0-beta.N

• Read the diff against origin/main
• Review release-please-config.json change
• Review doc changes (release-please-config.md, BETA_RELEASE_GUIDE.md)
• Verify the versioning: prerelease claim against config consistency
• Post review feedback

Verdict: LGTM. The config change is minimal, correct, and now byte-for-byte consistent with the already-proven eds-tokens entry. I verified the supporting claims where I could; one behavioural claim rests on the author's source reading and is worth a real confirming release.

---

What I verified

✅ Config parity is exact. The new eds-core-react-next entry (release-please-config.json:33-35) adds the same three keys eds-tokens already carries (release-please-config.json:89-91). Adopting a config that's already shipping in this repo is the right, low-risk move.

✅ Manifest state matches the PR body. Both eds-core-react-next and eds-tokens are at 3.0.0-beta.1 in .github/release-please-manifest.json, and .../next/version.txt reads 3.0.0-beta.1. No reset/bootstrap needed, as claimed.

✅ "No workflow changes needed" is accurate. publish_core_react.yaml:146 reads the beta version straight from .../next/version.txt (tr -d '[:space:]' < .../version.txt), which release-please owns. The publish path is decoupled from the versioning strategy — correct.

✅ feat/fix → counter-only bump is empirically proven. The eds-tokens 3.0.0-beta.0 → 3.0.0-beta.1 release (identical config, same repo) is direct evidence that a non-breaking commit only increments the counter at a X.0.0-beta.N base.

✅ No stale guidance left behind. Grepped for lingering "no ! in beta" / 2.0.1-beta copy — the only remaining hits are immutable CHANGELOG history. The doc updates are internally consistent.

---

Worth a second look (non-blocking)

1. The breaking-! claim is the one thing not yet proven in-repo — and the docs now actively recommend !.
The feat/fix behaviour is backed by a real release; the "! only bumps the beta counter (never rolls to 4.0.0-beta.0)" behaviour is not — eds-tokens hasn't shipped a breaking ! in its beta series yet. This is exactly the failure mode the old docs warned about, and the new docs now steer contributors toward !. The PR body cites a reading of prerelease.ts, but I couldn't independently re-verify the release-please source in this environment (no network / package not installed locally).

Recommendation: treat the first breaking /next beta as a checkpoint — confirm it lands as 3.0.0-beta.N+1 and not 4.0.0-beta.0 before the team fully relies on the guidance. If you want belt-and-suspenders, a BREAKING CHANGE: footer + a watchful eye on the first such release PR is enough. Not a blocker for merging the config.

2. Minor: the "mechanism" explanation is slightly imprecise.
In release-please-config.md, the line "At 3.0.0-beta.N (minor and patch are both 0), every commit type … bumps only the beta counter" conflates two things. Once a -beta.N suffix is present, the prerelease strategy increments the counter regardless of commit type — that's what pins the base. The minor/patch being 0 is what makes graduation land cleanly on 3.0.0 (rather than, say, 3.2.0 with phantom gaps). The practical outcome you describe is right; the causal framing could be tightened. Purely editorial.

3. Trivial: key ordering. The two entries list the same three keys in different order (versioning, prerelease, prerelease-type for tokens vs prerelease, prerelease-type, versioning here). Functionally irrelevant in JSON — mentioning only because matching order aids side-by-side grep/diff of the two entries.

---

Overall this is a clean, well-evidenced simplification of #5141's original approach — leaning on release-please's native strategy instead of custom workflow automation is clearly the better path. Ship it; just keep an eye on the first breaking beta release to close the loop on point 1.
· ci/pin-next-beta-3.0.0

[pomfrida]

Thanks for the review — addressing the three points:

1 (breaking-! unproven in-repo): Agreed on the checkpoint. The first breaking /next release after this merges is the open BEM branch (fix! commits) — it must land as 3.0.0-beta.2, not 4.0.0-beta.0. For the record, the source was verified directly against release-please v17 (src/versioning-strategies/prerelease.ts, bundled as 17.6.0 in release-please-action@v5), not just recalled: PrereleaseMajorVersionUpdate.bump increments only the prerelease counter when minor === 0 && patch === 0.

2 (doc framing "imprecise"): Pushing back on this one — the source says the opposite of the suggested correction. A prerelease suffix alone is not sufficient for counter-only bumps:

• PrereleaseMinorVersionUpdate.bump (a feat) only bumps the counter when version.patch === 0; at e.g. 3.0.1-beta.0 it falls through to MinorVersionUpdate and rolls the minor.
• PrereleaseMajorVersionUpdate.bump (a breaking change) only bumps the counter when version.patch === 0 && version.minor === 0; at e.g. 3.1.0-beta.2 it falls through to MajorVersionUpdate and rolls the major.

So "at 3.0.0-beta.N (minor and patch are both 0), every commit type bumps only the beta counter" is the precise precondition, not a conflation — minor=0/patch=0 is exactly what makes the pin hold for breaking commits too, in addition to making graduation land cleanly on 3.0.0. Keeping the doc wording as is.

3 (key ordering): Fixed in bb35fd9 — the next entry now lists versioning, prerelease, prerelease-type in the same order as the eds-tokens entry.