Re: FW: [nvda-translations] Changes to release process

Brian's Mail list account <bglists@...>

See my comments on the dev list, but to me the naming needs to be different
as many here use master as a working copy cos its stable this change will
dump them into the bleeding edge chain.
I'd propose doing away with master and keeping next instead, and yes I did
read the post but in reality changing a name is no different on one branch
than on another, then people who are on master will migrate to beta as they
become available staying on reasonably stable code. I can see tears before
bedtime otherwise when a bleeding edge update screws up somebody's working
copy who might not have read these messages on this list.
I think this makes more sense from the users point of view and does not mean
a master user has to do anything at all.
Brian using logic for a change!
Sent via blueyonder.
Please address personal E-mail to:-, putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Joseph Lee" <>
To: <>
Sent: Wednesday, July 04, 2018 3:13 AM
Subject: [nvda] FW: [nvda-translations] Changes to release process

Dear NVDA community,

Please read the updated release process document from NV Access (linked in the message below).

In short:
1. No more dedicated bleeding-edge next snapshots: what used to be next branch will now become master branch in the future.
2. A dedicated "beta" branch has been created on NVDA screen reader source code, used for stabilization work.
3. Approximately seven weeks before release of the next version, whichever stable code that is in master branch will be merged into the beta branch and will undergo two weeks of stabilization. This means you'll see increase in activity from beta branch around early January, early April, early July, and early October.
4. Around middle of January, April, July, and October, a beta build might be released. A series of beta builds are released, culminating in release candidate, and if no changes were made between the latest candidate in a week, a stable version will hit the air.

For users: many of you do not have to worry about this change, as majority of users are using stable releases.

For snapshot testers:
* If you are on next, you'll be moved to master branch when the new process takes effect.
* If you are on master, it'll be similar in nature to next snapshots of today.
* If you want to provide feedback on what is now master snapshots (beta builds in the future), please wait until the first beta for 2018.3 hits the air before switching to beta channel.
* Regardless of which branch you are using now (and master branch for everyone in the future, or perhaps beta builds), early feedback matters, so please do file them on GitHub (if you need to file an issue here, feel free to do so, and Quentin and/or another contributor will create a GitHub issue on your behalf).

For developers (especially for third parties writing new features): the following is a copy of my notes to be sent to the development list:

1. Please work from a topic branch: a topic branch is NOT your master branch - it is a separate branch that is forked from latest NV Access's master branch at the time you start your work, with commits sent to your fork of NVDA source code, not to NV Access directly yet.
2. Have a plan as you work: be sure to clearly define what you're working on, including data you need, debug plans, messages, impact and what not.
3. Test, test, test: just because your changes work for you doesn't mean it works for others, so be sure to test your work in various scenarios.
4. Run unit tests and other forms of tests: before committing your work (or submitting a pull request), be sure to run "scons tests" to really make sure your modifications does not break anything. This is important right before creating a pull request, as Appveyor will also run tests and will let you know if it breaks.
5. Document things: whenever you introduce a feature, document it in the user guide under appropriate section(s). Also, in case you're creating a brand new module in NVDA, please provide a short docstring (at the top of the file) explaining what your new module is, use cases and what not.
6. Help translators understand your message: if your work includes new messages, please do two things before submitting a pull request: make it translatable (unless justification is present), and accompany it with translator comments.
7. Keep up with others around the world: sometimes, a feature introduced by another person may (drastically) affect your work. This is the case especially if dependencies are changed, API changes occur and what not. Be sure to keep an eye on commits to NV Access's master branch, and if the change in there applies to your work, merge the master branch into your topic branch (not the other way around).
8. Do not be afraid to stand up to reviewers: during pull request discussion, you'll get feedback from reviewers (including NV Access people and others). If you believe the reviewer is having difficulty understanding your "intentions" (code edits), be prepared to provide a helpful explanation or two so you and the reviewer can be on the same page.
9. Approval != (not equal to) release: even with another person approving your feature, the world won't see it in action until NV Access approves your work and merges your pull request into master branch.
10. Test, test more, and test even more: just because your pull request is merged into master branch does not mean your work is over: it is just beginning. As user feedback comes in and based on follow-up tests, you might be asked to make changes to your work (or you can provide updates in the form of another pull request on your own).


-----Original Message-----
From: <> On Behalf Of Michael Curran
Sent: Tuesday, July 3, 2018 6:43 PM
To: NVDA screen reader development <>;
Subject: [nvda-translations] Changes to release process

Hi contributors,

We have made some small changes to the NVDA release process. Please read the updated Release Process article carefully to understand the changes and how they will affect you.

In short, Next/incubation is going away, and prs are going to be merged straight to master. Periodic betas will be offered startin from 5 weeks before a release.

Please read the entire article to understand the changes fully.

Translators should not be directly affected by this change. Though technically, translations are now based on a new "beta" branch rather than master.


Mick Curran
Executive Director, NV Access Limited
PH: +61 7 3149 3306 ext. 101
Twitter: @NVAccess

Join to automatically receive all group messages.