SemVer for design tokens

Design tokens are an API. Consumers depend on names (the contract) and resolved values (the rendered output). Compute the bump from a structured diff between successive snapshots — humans don't pick the bump; the diff does.

When to use

• Computing the next version number for a token release.
• Auditing a proposed release for under- or over-stated severity.
• Reviewing a PR that changes tokens and the proposed bump.
• Reading a token-tree diff and classifying each entry by SemVer impact.

When NOT to use

• Non-token releases (purely tooling changes, docs, build infrastructure). Use ordinary SemVer for those.
• Internal-only releases that have no external consumers — 0.x SemVer suffices, no formal compute needed.

The bump policy

The bump is computed from the diff between the previous published snapshot and the current. Each diff entry maps to a severity; the release's bump is the highest severity across all entries.