Release Process

This document provides rough guidelines for the process of developing NVDA releases. All current and potential developers should read and follow this document. These guidelines aren't intended to hinder the release process, but rather, to make it as smooth as possible. As such, they may be broken under special circumstances. Any concerns should be discussed with the lead developers.

Definitions

  • Lead developers: Michael (Mick) Curran (mdcurran), James (Jamie) Teh (jteh)
  • Internationalisation (i18n) coordinator: Peter Vágner
  • Main branch: The "main" bzr branch of the NVDA code, also known as trunk
  • Main branch committers: Anyone who has access to commit to the main branch
  • Release branch: A bzr branch based on the main branch from which pre-releases and the final release will be created
  • Translatable strings: Any strings that will affect translations; i.e. gettext strings enclosed in _().
  • Translatable string freeze: Translatable strings are frozen; i.e. no changes that affect translatable strings are allowed.

General

  • Tickets should be created for most issues.
  • A separate branch should be used for anything but very minor work, especially if it will need significant testing.
  • While patches are acceptable, branches are preferred, as they are easier to track and merge.
  • Main branch committers should seek code review and approval from the lead developers before committing any significant changes.
  • All changes visible to users since the last release should be documented in the what's new document.
    • Changes that affect a feature introduced in the release being developed need not be documented. This is because the feature didn't exist in the previous release, so the change isn't visible. The entry for the new feature might need to be updated, however; e.g. if the keyboard command changed.
    • If you are working in a branch, you should include the what's new entry in that branch.

Development

  • This is development of the next release and occurs in the main branch.
  • New features, changes and fixes may all be included and are allowed to affect translatable strings.
  • The lead developers will determine when the release should be made with some input from other developers.

Beta Release

  • A beta is released when it is determined that the code is ready for wide spread testing by the public.
  • New features should only be added if the lead developers consider them especially beneficial for the release.
  • Improvements, bug fixes and optimisations are all acceptable, assuming they are thoroughly tested.

Translatable String Freeze

  • Before a release candidate, a release branch will be created for the new release.
  • The release branch will enter a translatable string freeze.
  • After the freeze, the release branch will remain frozen for at least 3 weeks before the final release.
  • Translators should ensure that their translations are up to date during this period.
  • All translations must be based on the release branch.
  • New features should not be added.
    • Improvements, bug fixes and optimisations are all acceptable, assuming they are thoroughly tested.
    • From this point, development on the next release will continue in the main branch.

Release Candidate

  • Once it has been determined that the release is nearly ready to be declared final/stable, a release candidate will be released.
  • During this phase, the release branch remains in the translatable string freeze.
  • Only major bug fixes should be included.
  • Any other changes (even minor) require approval from the lead developers.