ReleaseProcess

Release Process

This document provides rough guidelines for the process of developing NVDA releases. All current and potential developers and translators should read and follow this document. These guidelines may be broken under special circumstances. Any concerns should be discussed with the lead developers: Michael (Mick) Curran (@MichaelDCurran), James (Jamie) Teh (@jcsteh).

Release Workflow

This is the general release workflow. Information for specific community groups is provided in later sections.

Development

• Work should be done in topic branches.
• A topic branch should be submitted for inclusion using a pull request.
• All pull requests must be reviewed by one of the lead developers.
• The "next" branch contains items being tested for possible inclusion in upcoming releases. Once an item is ready for testing for inclusion in an upcoming release, its pull request should be merged into the next branch.
• The "master" branch contains items that will be in the next release. When an item has been tested on the next branch without any commits and unresolved problems for 2 weeks, it may be merged into the master branch. Generally, this should be a squash merge.

Translatable String Freeze

• 3 weeks before the release is due, the master branch will enter a translatable string freeze for 2 weeks. That is, no changes to text strings that affect translations are allowed. Minor spelling or grammatical fixes may be made to documentation files, but gettext strings in the code should not be changed at all.
• Only bug fixes and translation updates should be committed to the master branch.

Release Candidate

• After the translatable string freeze, the "rc" branch will be created based on the master branch. The master branch will continue with normal development.
• The first release candidate will immediately be released from the rc branch.
• After this, only major bug fixes should be committed to the rc branch.
• Subsequent release candidates may be released.
• The final release can only be made if there have been no commits and at least 1 week since the last release candidate.

Representation on GitHub

• For most items, an issue will be filed and discussed before a pull request is submitted.
• If priority should be given to an issue for inclusion in a specific release, its milestone should be set to the appropriate release milestone (e.g. 2014.4).
• Once a pull request is merged into the next branch, the "incubating" label should be applied to the pull request.
• This will be done automatically if "Incubates #xxxx" is specified as the message when merging, where xxxx is the pull request number.
• Once the code for an incubating pull request graduates to the master branch, the milestone for the issue (if any) and pull request should be set to the next release milestone (e.g. 2013.2) and it should be closed as fixed.
• Issues/pull requests for bug fixes for an rc should have their milestone set to the relevant release (e.g. 2013.2).

Scheduled Releases

• Generally, final releases will be due around 22 February, 22 May, 22 August and 22 November. The exact date for each release will be determined by the lead developers.

Maintenance Release

• Under rare circumstances, a maintenance release (e.g. 2013.1.1) may be made.
• A maintenance release may only include fixes for crashes and major security issues.
• Maintenance releases are made from the rc branch.

For Developers

• GitHub issues should be created for most issues and discussed first before submitting a pull request. However, some trivial changes might not require an issue first. See Contributing for details.
• All new work should be based on the master branch unless it is for a maintenance release.
• Work should be done in a separate topic branch.
• Any relevant documentation should be included in the topic branch.
• New commands, drivers, settings, dialogs, etc. must be documented in the User Guide.
• Topic branches should be submitted as pull requests against master.

For Translators

• All translation should be based on the master branch.
• Translators should ensure their translation is up to date a day before the translatable string freeze ends in order for it to be included in the upcoming final release. The lead developers will announce the deadline when the freeze begins, but it will generally be close to UTC 00:00 on 14 February, 14 May, 14 August and 14 November. Work submitted after this time will not be included in the upcoming release.

For Testers

• The master branch is beta quality. It includes code that will be in the next release and has been tested without reported issues for at least a few weeks.
• The next branch is bleeding edge. It includes code that is being tested for possible inclusion in upcoming releases, but it may not yet be tested much (if at all) and there may be major bugs.