Releasing a breaking change without forcing upgrades

WHAT THIS TESTS This checks whether you correctly classify changes under semantic versioning and understand that consumers, not the library, control when they adopt a breaking release.

A GOOD ANSWER COVERS First, classify honestly. A padding change alters visual layout and can shift surrounding content, so it is a breaking change, not a patch, even though no API signature changed. Under semver that means a major version bump. The key insight is that publishing a new major does not force anyone to upgrade: consumers depend on a caret or pinned range, so they stay on the previous major until they choose to bump. The old major remains installable on the registry. Use Changesets: the author adds a changeset file marking the package major and writing human-readable migration notes; on merge, the release workflow consumes changesets to compute the version, update the changelog, and publish. Communicate via the changelog, a deprecation window, and where feasible a codemod or migration guide so teams upgrade on their own schedule.

COMMON WRONG ANSWERS Releasing the change as a patch or minor to avoid a major bump, silently breaking layouts. Forcing all apps to a new version at once. Unpublishing the old version. Treating visual-only changes as never breaking.

LIKELY FOLLOW-UPS How do you decide if a visual change is truly breaking. How do you support two majors at once. How does a codemod ease migration.

ONE CONCRETE EXAMPLE The Button padding change ships as version 4.0.0 with a Changeset noting Button padding increased, review layouts. Teams on the caret-3 range keep getting 3.x updates untouched; when ready, a team bumps to 4.x, reads the migration note, and adopts the change on its own timeline.