Documentation

How Amber releases work

New
Browse documentation

Published 2026-11-01. V2 is a prerelease; the web core is release-gated and other previews are named separately. What beta means.

View Markdown View JSON Open in Claude Open in ChatGPT Copy + open Gemini

Read this page as HTML, Markdown, or structured JSON—or open the published Markdown with an AI assistant. Gemini receives the prompt through your clipboard because its signed-out page does not reliably prefill URL text; paste when the new tab opens. External assistants need the public site URL.

1.4.1
Unavailable in this version
1.5
Unavailable in this version
2.0

How Amber releases work

Every Amber release is a tag. What you install or visit always comes from a tag, never from a branch.

Who decides

Seth Tucker, the project lead, decides what goes into each release and when it ships. Maintainers review the work; the governance page describes their part.

Where work lands

Merged pull requests land on each repository's development branch. For Amber V2 that is v2-dev in the framework repository, main in the CLI repository, and master for this website. A development branch is where work collects; it is never a release. For an app you depend on, install from a release tag.

How the next release is chosen

A release branch, release/next, collects the changes chosen for the next release. Only changes already merged to the development branch move to it. The project lead chooses which of those changes go in.

How a release is tagged

When the chosen group passes CI, its commit gets a tag that never moves. The framework and its libraries use version tags, for example v2.0.0-beta.5. This website uses date tags, for example site-2026.11.1. Each release names its full commit hash and the sha256 of every file it publishes. The release tracker records each tag's commit and published file digests.

How a release reaches you

Shards and the CLI install from release tags, pinned by your shard.lock. This website is deployed only from its release tags, after CI builds and tests that exact commit.

How a release is rolled back

Rolling back means redeploying the previous tag. Earlier tags stay published, so an app can pin the previous version and the website can redeploy its previous tag. A fix ships as a new tag; a published tag is never changed.

Where to follow along

Release notes and their files are on each repository's GitHub Releases page. The release contract describes what a release must prove before it ships.