Prepare a release

A release is a permanent package captured from one branch snapshot. Preparing it does not publish it. Later branch edits, renames or deletion do not change a completed release.

Permissions and prerequisites

Owner, Admin and Editor can prepare releases in active workspaces, projects and branches. Viewer can read releases, validation reports and content. Release creation requires at least one active key and language. Restore archived content before preparing a new package.

Build a package

1. Select your workspace, project and branch in the header.
2. Open Releases in the project sidebar. Create release shows the source branch explicitly; use Source branch to choose another.
3. Enter an optional description and minimum/maximum application versions. Bounds are inclusive and use strict SemVer, such as 1.4.0 or 2.0.0-rc.1. Leave a bound empty for no limit. A release number is not an application version.
4. Leave Languages empty to include all active languages, or select requested languages. Select Include or Exclude tags when needed. Include matches any selected tag; exclude takes priority.
5. Select Build release. Follow Release operations until preparation completes, then open the release.
6. Review immutable content, validation and compatibility before publishing.

The source content token is checked under lock. If the branch changed before capture, preparation stops with a conflict; refresh and review the branch before starting another release. Once captured, retries use that snapshot. Cancel is available before the build completes. Owner/Admin can manage eligible jobs; Editor can manage their own build jobs.

Selection and fallback

Only active keys and languages enter a release. The package automatically includes active languages required by each requested language’s configured fallback chain. The report separates requested languages from dependencies.

For each key and requested language the report counts:

• Direct: that language contains a value.
• Fallback: another language in its explicit chain supplies a value.
• Missing: no value exists anywhere in that chain.

Missing is represented as null, not an empty string. A release does not fill database cells, change Missing filters or create automatic regional fallbacks. Plain text whitespace and ICU contracts are preserved. When ICU resolves through another language, use that value’s locale when formatting plurals.

Dependencies’ missing cells are not publication blockers when the requested language already resolves successfully. Any unresolved requested cell blocks Production; Preview permits it and retains the diagnostic.

Review compatibility

The release detail includes paginated content and diagnostics. Compare releases shows added, removed and changed entries, values and ICU contracts. Check removed keys, reduced language coverage and changed argument contracts against application code. A successful build cannot prove application compatibility: declare the intended version range and test the package in Preview.

Captured selections, compatibility and package contents are immutable. Create another release to change them. Releases, required snapshots and publication history do not expire automatically. Branch deletion does not remove them, and unfinished release builds appear in branch deletion blockers.

Limits and failures

Each preparation is limited to 10,000 keys, 50,000 key/language values including Missing cells, and 100 MiB of source and generated content. The build runs in a separate bounded process. An over-limit selection fails as a whole; narrow languages or tags and create a new release. A temporary failure can be retried without capturing different source content. Conflicts require a fresh reviewed request.