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 (mdcurran), James (Jamie) Teh (jteh).

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.
• 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, it 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.

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 in Issue Tickets

• If priority should be given to a ticket for inclusion in a specific release, its milestone should be set to the appropriate release milestone (e.g. 2014.4).
• Once code for a ticket is merged into the next branch, the ticket's status should be set to "incubating".
• Once the code for an incubating ticket graduates to the master branch, the milestone should be set to the next release milestone (e.g. 2013.2) and it should be closed as fixed.
• Tickets 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

• Tickets should be created for most issues.
• 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.
• While patches are acceptable, branches are preferred, as they are easier to track and merge.
• Any relevant documentation should be included in the topic branch.
• New commands, drivers, settings, dialogs, etc. must be documented in the User Guide.

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.