Publishing

What happens when you publish

When you publish, ReframeUI captures a snapshot of your current main token state, assigns a semantic version number, and builds a new package artifact. If you have GitHub integration connected, a pull request is opened in each consumer repo with the updated package.

Before the publish completes, Studio shows a confirmation dialog. It displays the next version number, the number of tokens that changed, and a list of any breaking changes detected. Review this before confirming.

Versioning

ReframeUI uses semantic versioning: major.minor.patch. The version bump is calculated automatically based on what changed.

• •A patch bump applies when a token's value changed and its name and type stayed the same.
• •A minor bump applies when a new token was added.
• •A major bump applies when a token was removed, renamed, or its type changed.

If multiple changes are present, the highest applicable bump wins. You can override to a major bump from the confirmation dialog before publishing.

The default bump thresholds can be raised on a per-change-kind basis in Project Settings. See Token Enforcement Settings.

Breaking change detection

A breaking change is any modification that would cause a consumer's code to reference a token that no longer exists or has a different type. Removed tokens, renamed tokens, and type changes are all breaking.

The confirmation dialog lists each affected token, the type of change, and the previous value. Review this list before confirming a major publish.

To see the diff and breaking change list without publishing, run:

reframe publish --dry-run

This prints the full change summary to your terminal and exits without creating a new version.

To require a review before a publish can go out, see Branch Review and Approval.

Consumer repo pull requests

When a publish completes and GitHub integration is connected, ReframeUI opens a pull request in each consumer repo. The PR contains the updated package version pin, a summary of token changes, and a link to the ReframeUI changelog for that version.

ReframeUI tracks the CI status of each consumer PR and surfaces it on the Publish history page in Studio: green, red, or pending. Merging the PR is the consumer team's responsibility. ReframeUI cannot merge it automatically.

Version pinning

A consumer can hold at a specific version by setting the version field in their reframe.config.ts:

export default {
  version: "2.3.0",
};

While a pin is set, ReframeUI suppresses automatic update pull requests for that consumer. Remove or update the pin when ready to receive newer versions.

Rollback

Rollback works by publishing a new version from a previous snapshot. There is no destructive undo and no version history is removed.

There are two ways to roll back:

In Studio: go to Publish history, find the version you want to restore, and click Restore this version. This creates a new publish from that snapshot. The normal consumer PR flow runs again.

Via CLI: run reframe publish --from-version followed by the version number:

reframe publish --from-version 2.3.0

The version number must match a previously published version. The resulting publish gets the next version number, not the original one.

For managing token changes before publishing, see Branching Workflow. For the full list of publish commands and flags, see CLI Reference. To set up Slack alerts for publish events, see Notifications and Alerts.