> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/nvaccess/nvda/llms.txt
> Use this file to discover all available pages before exploring further.

# Release Process

> Understanding NVDA's release workflow and how releases are developed

This document provides guidelines for the NVDA release process. All current and potential developers, add-on developers, and translators should understand this workflow.

<Info>
  These guidelines may be adapted under special circumstances. Any concerns should be discussed via [GitHub Discussion](https://github.com/nvaccess/nvda/discussions), issue, or pull request.
</Info>

## Release Workflow Overview

Each NVDA release progresses through four main phases over approximately 14 weeks:

<Steps>
  <Step title="Alpha Phase" icon="flask">
    \~7 weeks of active development with unstable add-on API
  </Step>

  <Step title="Beta Phase" icon="vial">
    \~4 weeks of testing and refinement with weekly beta releases
  </Step>

  <Step title="Release Candidate Phase" icon="check-double">
    \~3 weeks including translation freeze and RC builds
  </Step>

  <Step title="Final Release" icon="rocket">
    Stable release deployed to users worldwide
  </Step>
</Steps>

<Note>
  Development of the next version occurs in parallel with the release process. For example, NVDA 2026.2 alpha development happens while 2026.1 progresses from beta to final release.
</Note>

## Alpha Phase

**Duration**: \~7 weeks

### What Happens

* Active feature development on the `master` branch
* Pull requests reviewed and merged by NV Access
* Automatic alpha snapshot builds generated for early testing
* Add-on API is **unstable** during this phase

### For Developers

<CardGroup cols={2}>
  <Card title="Contributing Code" icon="code" href="https://github.com/nvaccess/nvda/blob/master/projectDocs/dev/contributing.md">
    Follow the development contributing guide
  </Card>

  <Card title="Alpha Snapshots" icon="download" href="https://download.nvaccess.org/snapshots/alpha/">
    Test your contributions early
  </Card>
</CardGroup>

### Pull Request Process

<Steps>
  <Step title="Review and Approval">
    PRs must be reviewed and approved by at least one NV Access employee with all build checks passing
  </Step>

  <Step title="Squash Merge">
    Approved PRs are squash merged into the `master` branch
  </Step>

  <Step title="Build Check Failures">
    If a merged PR causes build checks to fail on `master`, it is reverted immediately without question
  </Step>

  <Step title="Regression Handling">
    PRs identified as causing regressions may be reverted at the discretion of lead developers
  </Step>
</Steps>

<Warning>
  Use the [PR revert template](https://github.com/nvaccess/nvda/blob/master/.github/PULL_REQUEST_TEMPLATE/revert.md) when reverting changes.
</Warning>

### For Add-on Developers

<Card icon="puzzle-piece">
  Add-ons targeting this release should use the **"dev" channel** due to API instability.
</Card>

## Beta Phase

**Duration**: \~4 weeks

### What Happens

* A stable commit from `master` is merged into the `beta` branch
* **Feature freeze**: The line is drawn for features in this release
* Weekly beta releases for wider testing
* Documentation reviewed and release summary added to changelog
* Translations become relatively stable
* Add-on API stabilizes

### Beta Release Schedule

<Info>
  * **Beta 1** is released 1 week after the most recent final release
  * **Exception**: For 20XX.1 releases, Beta 1 occurs after all planned API breaking changes are complete
  * New betas released weekly as required
</Info>

### What Can Be Merged to Beta

New pull requests may be merged directly to beta if they address:

* Regressions introduced in this release
* Bugs in "must have" features for this release
* Critical OS changes out of our control

### Beta-to-Master Merges

The `beta` branch is merged back into `master` as necessary for:

* Critical pull requests
* Translation merges

### Regression Handling

<Warning>
  If a merged PR in beta causes a regression:

  * It may be reverted by lead developers
  * It may be fixed if the bug is trivial enough
  * Once reverted from beta, a replacement PR is **very unlikely** to be accepted in the current release
</Warning>

### For Add-on Developers

<Card icon="puzzle-piece">
  Add-ons can use the **"dev" or "beta" channel**. Start testing with the new API, but further changes may occur.
</Card>

### For Translators

<Card icon="language">
  Translations should be relatively stable. You may start working on the release, though further string changes will occur.
</Card>

## Release Candidate Phase

**Duration**: \~3 weeks

### Translation Freeze

<Steps>
  <Step title="Freeze Begins">
    Once a beta has been stable for one week (no issues reported), a **2-week translation freeze** begins
  </Step>

  <Step title="No String Changes">
    No changes to translatable strings are allowed. Minor spelling/grammatical fixes to documentation are permitted, but `gettext` strings in code must not change
  </Step>

  <Step title="Translator Deadline">
    Translators should complete work **one day before the freeze ends** to be included in the release
  </Step>

  <Step title="Announcements">
    Lead developers announce the deadline on the [NVDA-Translations message board](https://groups.io/g/nvda-translations/)
  </Step>
</Steps>

<Warning>
  Work submitted after the translation deadline will **not** be included in the upcoming release.
</Warning>

### Release Candidate Builds

<Steps>
  <Step title="RC Branch Created">
    After the translation freeze, the `rc` branch is created from the `beta` branch
  </Step>

  <Step title="First RC Released">
    The first release candidate is immediately released from the `rc` branch
  </Step>

  <Step title="Critical Fixes Only">
    Only critical bug fixes should be committed to the `rc` branch
  </Step>

  <Step title="Subsequent RCs">
    Additional release candidates may be released as needed
  </Step>

  <Step title="Final RC Requirements">
    The final RC should be identical to the final release
  </Step>
</Steps>

### Final Release Requirements

<Card icon="check-circle">
  The final release can only be made if:

  * No significant changes since the last RC
  * At least 1 week has passed since the last RC
  * No serious issues reported
</Card>

### For Add-on Developers

<Card icon="puzzle-piece">
  The add-on API is **stable** during RC. Add-ons targeting this release can use the **"stable" channel**.
</Card>

## Final Release

When a release candidate has been stable for one week with no reported issues, the final release is created and distributed.

### After Release

<Card icon="champagne-glasses">
  Congratulations! The release is complete. The next alpha cycle begins immediately.
</Card>

## Patch Releases

Under rare circumstances, patch releases (e.g., 2026.1.1) may be made.

### Criteria for Patch Releases

<Warning>
  Patch releases may **only** include fixes for:

  * Crashes
  * Major security issues
</Warning>

<Info>
  Patch releases are made from the `rc` branch.
</Info>

## GitHub Representation

### Issue and PR Management

<Steps>
  <Step title="Issue Discussion">
    Most items have an issue filed and discussed before a PR is submitted
  </Step>

  <Step title="Milestone Assignment">
    Issues prioritized for a specific release have their milestone set accordingly (e.g., 2026.2)
  </Step>

  <Step title="PR Merged">
    When a PR is squash merged to `master`, its milestone is set to the next release
  </Step>

  <Step title="Issue Closed">
    Associated issues are closed as fixed when the PR is merged
  </Step>

  <Step title="Beta/RC Fixes">
    Issues/PRs for beta or RC bug fixes have their milestone manually set to the relevant release
  </Step>
</Steps>

## Release Schedule

### Frequency

<Info>
  NVDA is released approximately **4 times per year** on a frequency-based schedule rather than targeting specific calendar dates.
</Info>

The release cycle is roughly:

* 3-4 months between releases
* 14 weeks total from alpha start to final release
* Determined by stability rather than calendar dates

### Special Timing Considerations

<Note>
  **20XX.1 releases** may take slightly longer than other releases due to managing API breaking changes.
</Note>

## For Different Community Groups

### Developers

<Card title="Development Guide" icon="code" href="https://github.com/nvaccess/nvda/blob/master/projectDocs/dev/contributing.md">
  Learn how to contribute code during the alpha and beta phases
</Card>

### Translators

<Card title="Translation Guide" icon="language" href="https://github.com/nvaccess/nvda/blob/master/projectDocs/translating/readme.md">
  Understand translation deadlines and the freeze process
</Card>

### Add-on Developers

<Card title="Add-on Development" icon="puzzle-piece" href="https://github.com/nvaccess/nvda/blob/master/projectDocs/dev/addons.md">
  Learn about add-on channels and API stability during each phase
</Card>

### Testers

<Card title="Testing Guide" icon="vial" href="https://github.com/nvaccess/nvda/blob/master/projectDocs/testing/contributing.md">
  Help test alpha snapshots, beta releases, and release candidates
</Card>

## Staying Informed

To keep up with the release process:

* Watch the [NVDA GitHub repository](https://github.com/nvaccess/nvda)
* Subscribe to relevant [mailing lists](/community/mailing-lists)
* Monitor [GitHub milestones](https://github.com/nvaccess/nvda/milestones)
* Check the [changelog](/community/changelog) for upcoming features