Skip to main content
This document provides guidelines for the NVDA release process. All current and potential developers, add-on developers, and translators should understand this workflow.
These guidelines may be adapted under special circumstances. Any concerns should be discussed via GitHub Discussion, issue, or pull request.

​
Release Workflow Overview

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

Alpha Phase

~7 weeks of active development with unstable add-on API

Beta Phase

~4 weeks of testing and refinement with weekly beta releases

Release Candidate Phase

~3 weeks including translation freeze and RC builds

Final Release

Stable release deployed to users worldwide
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.

​
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

Contributing Code

Follow the development contributing guide

Alpha Snapshots

Test your contributions early

​
Pull Request Process

1

Review and Approval

PRs must be reviewed and approved by at least one NV Access employee with all build checks passing
2

Squash Merge

Approved PRs are squash merged into the master branch
3

Build Check Failures

If a merged PR causes build checks to fail on master, it is reverted immediately without question
4

Regression Handling

PRs identified as causing regressions may be reverted at the discretion of lead developers
Use the PR revert template when reverting changes.

​
For Add-on Developers

Add-ons targeting this release should use the “dev” channel due to API instability.

​
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

  • 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

​
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

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

​
For Add-on Developers

Add-ons can use the “dev” or “beta” channel. Start testing with the new API, but further changes may occur.

​
For Translators

Translations should be relatively stable. You may start working on the release, though further string changes will occur.

​
Release Candidate Phase

Duration: ~3 weeks

​
Translation Freeze

1

Freeze Begins

Once a beta has been stable for one week (no issues reported), a 2-week translation freeze begins
2

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
3

Translator Deadline

Translators should complete work one day before the freeze ends to be included in the release
4

Announcements

Lead developers announce the deadline on the NVDA-Translations message board
Work submitted after the translation deadline will not be included in the upcoming release.

​
Release Candidate Builds

1

RC Branch Created

After the translation freeze, the rc branch is created from the beta branch
2

First RC Released

The first release candidate is immediately released from the rc branch
3

Critical Fixes Only

Only critical bug fixes should be committed to the rc branch
4

Subsequent RCs

Additional release candidates may be released as needed
5

Final RC Requirements

The final RC should be identical to the final release

​
Final Release Requirements

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

​
For Add-on Developers

The add-on API is stable during RC. Add-ons targeting this release can use the “stable” channel.

​
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

Congratulations! The release is complete. The next alpha cycle begins immediately.

​
Patch Releases

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

​
Criteria for Patch Releases

Patch releases may only include fixes for:
  • Crashes
  • Major security issues
Patch releases are made from the rc branch.

​
GitHub Representation

​
Issue and PR Management

1

Issue Discussion

Most items have an issue filed and discussed before a PR is submitted
2

Milestone Assignment

Issues prioritized for a specific release have their milestone set accordingly (e.g., 2026.2)
3

PR Merged

When a PR is squash merged to master, its milestone is set to the next release
4

Issue Closed

Associated issues are closed as fixed when the PR is merged
5

Beta/RC Fixes

Issues/PRs for beta or RC bug fixes have their milestone manually set to the relevant release

​
Release Schedule

​
Frequency

NVDA is released approximately 4 times per year on a frequency-based schedule rather than targeting specific calendar dates.
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

20XX.1 releases may take slightly longer than other releases due to managing API breaking changes.

​
For Different Community Groups

​
Developers

Development Guide

Learn how to contribute code during the alpha and beta phases

​
Translators

Translation Guide

Understand translation deadlines and the freeze process

​
Add-on Developers

Add-on Development

Learn about add-on channels and API stability during each phase

​
Testers

Testing Guide

Help test alpha snapshots, beta releases, and release candidates

​
Staying Informed

To keep up with the release process:

Build docs developers (and LLMs) love

Get started for freeTalk to us