Re: Suggestion for upcoming NVDA build
Hi everyone,toggle quoted messageShow quoted text
Let me give you a "backstage tour" regarding this issue and why the suggestion will not be implemented:
As you may know by now, NV Access produces at least three branches: rc (release candidate), master, and next. The rc branch is where the stable (and official) releases happen, master is perpetual beta, and next is alpha-level code (bleeding-edge). For those using Chrome (or are reading the Chrome thread) may have noticed a similar pattern: Canary is equivalent to NVDA next (alpha-level code and is built nightly), dev and beta are equivalent to NVDA master, and the release that gets used by many users is equivalent to NVDA stable build.
Sometimes, NV Access or others may produce other snapshots. In the past, NV Access was known for producing snapshots from branches that required public testing (such as feedback when entering Asian characters). At one point, I have produced third-party snapshots, ranging from Windows 10 support, support for newer processor instructions, initial support for Outlook Calendar, and most recently, UEB tests (my snapshots, unlike those of NV Access, does not support updates).
When we produce snapshots, we assume the following:
* Many people are using stable builds.
* Using a snapshot means more bugs.
* When users are installing snapshots, they do so either because they are adventurous or would like to test upcoming features.
Regarding the last point, in order to move from stable build to development branches and vice versa, you need to download and install the desired build in question. This is because of the following:
* NVDA keeps a record of the branch it should query when connecting to NV Access server to retrieve updates. You can "fool" NVDA to download a different snapshot via code, but it won't work (this record is constant and will revert back to its original string once NVDA restarts).
* When NVDA checks for updates, it'll check the branch in question, and will present the update prompt if the version you've got is different than that of the one hosted on the server.
* Unless silenced, NVDA will check for updates every 24 hours.
Thus, when "changing" branches, you need to do this willingly. Because snapshots are reserved for a specific audience (although stable build users could try them out), the user interface for specifying branches will not be implemented.
From: Pete [mailto:firstname.lastname@example.org]
Sent: Sunday, March 27, 2016 8:14 AM
Subject: Re: [nvda] Suggestion for upcoming NVDA build
Snapshot users use snapshots.
Main branch users use main versions.
This doesn't require the main branch to be modified and instead targets the wanted modification users, snapshot users with the update to snapshots witch is what they want rite?
The normal update channel will stil be there in the snapshot version so if a snapshot user wants to update to a main version she or he can do so if desired.
People using snapshots are more likely to upgrade snapshots.
Why clutter up nvda main with extra options they may, no more than likely use?
Having said all that, the option to update to snapshot versions in the main branchbrantch would keep the code consistant between main and snapshot.
if a snapshot user upgrades to a main version they would loose upgrade to snapshot version, so may be better to modifie the main branch.
Keeping the snapshot and main versions separate makes more sense.
It is less confusing for
snapshot users to update to snapshot version updates
main version users update to main version updates
respectively and exclusively.
On 3/27/2016 10:04 AM, Lenron wrote:
You should just have the option in the main version if you wish to