release: applying package updates (manual recovery) - #36619
release: applying package updates (manual recovery)#36619Martin Hochel (Hotell) merged 2 commits into
Conversation
70e69df to
b96ea1d
Compare
📊 Bundle size report✅ No changes found |
|
Pull request demo site: URL |
| { | ||
| "name": "@fluentui/react-infobutton", | ||
| "version": "9.0.0-beta.119", | ||
| "version": "9.0.1-0", |
There was a problem hiding this comment.
good catch, this is definitely wrong !
this is correct, and it's recording a (bad) release rather than causing one.
9.0.1-0 was actually published:
@fluentui/react-infobutton@9.0.1-0 published 2026-08-24T08:16:14Z
@fluentui/react-alert@9.0.2-0 published 2026-08-24T08:16:30Z
Why the version fell off the beta line
Not a beachball v3 bug — a config gap that beachball's downgrade heuristic exposes.
These packages carry "disallowedChangeTypes": ["major", "minor", "patch"] and have no change files of their own; they're bumped as dependents of react-popover etc., where the default dependentChangeType is patch. Beachball resolves a disallowed type by stepping exactly one notch down its ordered list:
SortedChangeTypes = ['none','prerelease','prepatch','patch','preminor','minor','premajor','major']So patch → prepatch
semver.inc('9.0.0-beta.119', 'prepatch') -> 9.0.1-0 <- what happened
semver.inc('9.0.0-beta.119', 'prerelease') -> 9.0.0-beta.120 <- what we wanted
Recovery/fix e881bc5
Manual release recovery
The v9 release pipeline run #383600 published all 36 packages to npm successfully**, but then failed when pushing the version bumps back to
master:As a result the packages are live on the registry while the repository still carries the previous versions. npm publishes are irreversible, so this PR moves the repository forward to match the registry.
What this PR does
yarn beachball bump --config scripts/beachball/src/release-vNext.config.js, consuming the change files the failed run never got to commitprecommitfixups a real release runs:dependency-mismatch,normalize-package-dependencies,yarn install --mode=update-lockfileNo versions were hand-edited. Everything is beachball-generated so changelogs and dependency ranges stay consistent.
Verification
A registry sync check confirms every previously desynced package now matches npm exactly:
Packages recovered (36)
Not included: release tags
Release git tags are intentionally not recreated. This commit is not the commit the release was built from, so tags pointing at it would misrepresent history, and a single v9 release spans dozens of packages. Tags are not load-bearing for consumers - npm is what they install from.
Follow-up required
The underlying cause is the GitHub credential used by the release pipeline. Until the PAT in the
Github and NPM secretsvariable group is rotated/fixed, the next release will fail in exactly the same way.