Versioning

Release types

@bigbang/tokens, @bigbang/ui and @bigbang/icons use semantic versioning and are versioned with Changesets. The docs site (@bigbang/docs) is not versioned.

Change	During 0.x	After 1.0
Bug fix, internal change users cannot see	Patch	Patch
New component, prop, variant or token	Minor	Minor
Breaking change: removing or renaming a prop or token, changing a default or a behaviour	Minor, with a migration note	Major, with a migration note

While the packages are at 0.x, breaking changes ship as minor releases. That is why the text of every breaking change includes a migration note.

Writing a changeset

Every change users can notice comes with a changeset:

pnpm changeset

1. Select the changed packages and the release type.
2. Write one or two sentences, from the point of view of the person using the change, in English. Put code names in backticks (`Button`); the What’s new page links these names to the component pages.
3. For a breaking change, write the old and the new use: Rename `appearance` to `variant`: `appearance="subtle"` becomes `variant="tertiary"`.
4. Commit the generated .changeset/*.md file with the change.

Changes users cannot notice, such as tests, the docs site and tooling, need no changeset. pnpm changeset status lists what goes into the next release. Bumping versions (pnpm changeset version) and publishing are done by the maintainers.

Component statuses

Status is separate from the package version and shows in the Components overview table.

Status	Meaning	Moving to the next status
Draft	Usable; the interface may change	Interface settled, checklist complete
Beta	Interface settled; first product use and manual accessibility testing under way	Screen reader test done, used on two screens
Ready	Breaking changes only in a major release	—
Deprecated	The replacement is named	Removed in the next minor release

Deprecation

1. The old component or prop points to its replacement with a @deprecated TSDoc tag (REUSE-10).
2. The status becomes “Deprecated”; the removal release is written on the Changelog tab.
3. Where possible, a codemod is added.
4. Removal happens in the next minor release. If usage grows in the meantime, the release is stopped.