{"title":"How Amber releases work","description":"Where work lands, how a release is chosen and tagged, and how a release is rolled back","section":"project","version":"v2","path":"project/how-amber-releases-work","canonical_url":"https://amberframework.org/docs/v2/project/how-amber-releases-work","markdown_url":"https://amberframework.org/docs/v2/project/how-amber-releases-work.md","inherited":false,"content_markdown":"# How Amber releases work\n\nEvery Amber release is a tag.\nWhat you install or visit always comes from a tag, never from a branch.\n\n## Who decides\n\nSeth Tucker, the project lead, decides what goes into each release and when it ships.\nMaintainers review the work; the [governance page](/docs/v2/project/governance) describes their part.\n\n## Where work lands\n\nMerged pull requests land on each repository's development branch.\nFor Amber V2 that is `v2-dev` in the framework repository, `main` in the CLI repository, and `master` for this website.\nA development branch is where work collects; it is never a release.\nFor an app you depend on, install from a release tag.\n\n## How the next release is chosen\n\nA release branch, `release/next`, collects the changes chosen for the next release.\nOnly changes already merged to the development branch move to it.\nThe project lead chooses which of those changes go in.\n\n## How a release is tagged\n\nWhen the chosen group passes CI, its commit gets a tag that never moves.\nThe framework and its libraries use version tags, for example `v2.0.0-beta.5`.\nThis website uses date tags, for example `site-2026.11.1`.\nEach release names its full commit hash and the sha256 of every file it publishes.\nThe [release tracker](https://amberframework.org/release-tracker/) records each tag's commit and published file digests.\n\n## How a release reaches you\n\nShards and the CLI install from release tags, pinned by your `shard.lock`.\nThis website is deployed only from its release tags, after CI builds and tests that exact commit.\n\n## How a release is rolled back\n\nRolling back means redeploying the previous tag.\nEarlier tags stay published, so an app can pin the previous version and the website can redeploy its previous tag.\nA fix ships as a new tag; a published tag is never changed.\n\n## Where to follow along\n\nRelease notes and their files are on each repository's GitHub Releases page.\nThe [release contract](/docs/v2/project/release-contract) describes what a release must prove before it ships."}