> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/concepts/release-candidates-and-releases.md).
# Release candidates and releases
The two are easy to conflate, and the distinction runs through every codev screen that mentions them:
* A **release candidate** is what is *ready* to deploy. codev creates them at the end of a build, whether that build came from a merge or from **Run build**.
* A **release** is what *has been* deployed. You create one by releasing a candidate, through an approval gate.
Candidates arrive with every merge; releases are made from them through the approval gate.
## Where candidates come from
Every merge that changes a domain's packages produces a new release candidate for that domain — automatically, as the tail end of the build. A build started with **Run build** on the Builds page produces one the same way, for the commit and packages you chose; see [Running a build manually](/flxbl/codev/ci-cd/overview.md#running-a-build-manually). A candidate records the exact package versions built, the work items that are new in it, and the cumulative work items accumulated since the last release. Domains that the merge did not touch get no new candidate.
Because a candidate arrives per merge, they stack up: the newest candidate for a domain is **Active**, and earlier ones become **Superseded**. Superseded is informational — an older candidate can still be deployed if you need exactly that state.
| Status | Meaning |
| -------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Active** | The newest candidate for the domain — ready to release or test. |
| **Released** | Deployed to at least one environment. It stays on the Release Candidates page, with a **Deployed to** indicator. |
| **Superseded** | A newer candidate exists for the domain. Still deployable. |
## A candidate deploys the accumulated state, not one merge
This is the point that trips people most. A candidate's package versions are the *latest built versions* of the domain's packages — so releasing it installs everything that has changed **since the last release**, not just the changes from the merge that created it.
The work items display exists for exactly this reason: each candidate shows the items *new in this candidate* alongside the *cumulative* set since the last release. When you request a release, the cumulative list is the honest scope of what you are about to ship — review that one, not just the newest items.
## From candidate to release
A candidate becomes a release through the **Release** action:
1. A **dry run** confirms which packages would install into the target environment.
2. The request waits at an **approval gate** — designated approvers review and approve or reject.
3. On approval, codev locks the environment, installs the artifacts, and unlocks it.
4. The result is recorded on the **Releases** page.
Each target environment gets its own approval and deploys independently — releasing the same candidate to staging and production are two gated releases, not one.
Deploying a candidate to a sandbox for testing does not go through this: **Get on Sandbox** installs the candidate without an approval gate and without creating a release. A release is only ever created by the Release action.
## Releases are the record
The Releases page is the deployment history: which versions went to which environment, when, carrying which work items. From a release you can create a **patch** branch to hotfix exactly what is in production, or **roll back** an environment to an earlier release.
The actions in detail: [Managing Release Candidates](/flxbl/codev/ci-cd/managing-release-candidates.md) · [Releases](/flxbl/codev/ci-cd/overview-3.md) · [Rolling back a release](/flxbl/codev/ci-cd/rollback.md) · [Work items](/flxbl/codev/ci-cd/work-items.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.flxbl.io/flxbl/codev/concepts/release-candidates-and-releases.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.