Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Noelia Ruiz

Just to clarify, my confusion was just a mistake, not a fault in NVDA. It was due to this code:

def isAddonTested(addon, backwardsCompatToVersion=addonAPIVersion.BACK_COMPAT_TO):
"""True if this add-on is tested for the given API version.
By default, the current version of NVDA is evaluated.

But this is not the same than the default value for the add-on manifest.


El 04/10/2019 a las 04:04, Noelia Ruiz via Groups.Io escribió:
Sorry, mistake: I meant that the last tested version, for development, could be set to the current alpha or beta. According with the developer guide it defaults to 0. Not to current. I will look at the code, since I maybe wrong, but I believe that I read that it defaults to te current versio used. I will look this again.
Enviado desde mi iPhone
El 4 oct 2019, a las 3:53, Noelia Ruiz via Groups.Io < <>> escribió:

You are reflecting interesting arguments. Anyway, I thing that this should be chosen by author in a case basis. Fon example, if they can avoid bugs before releasing an add-on under developmento or know them and dont need that people suffer these bugs, they can do it before. And in other cases, according with your arguments, authors can ommit the last tested version flag in add-ons under development or pre-released to be tested in alpha or beta versions of NVDA. Then, I think that the current flag is correctly designed, since it is not mandatory and, if it is not present, it will not enforze incompatibility and this can help to detect errors.
Very interesting.

Enviado desde mi iPhone

El 3 oct 2019, a las 16:29, derek riemer <driemer.riemer@... <mailto:driemer.riemer@...>> escribió:

On Wed, Oct 2, 2019 at 11:33 PM Noelia Ruiz <nrm1977@... <mailto:nrm1977@...>> wrote:

Hi, really, imo they shouldn't be exempt, since this could break
in the system like crashes

If you're signing up to test beta and alpha software, the expectation is that there will be crashes. I'd much rather a developer discover that their addon isn't compatible, or is crashing NVDA, so the flags can be updated, and make the ease of developing their addon maximally easy on developer editions, because these editions are designed to surface errors before they reach the general public. On developer editions, for example, addon authors get error sounds, which allow them to detect problems in the addon. I could be easily persuaded to allow the minimNVDAVersion flag to be honored in developer editions, for sure, but I'd rather not torture developers with untested addons warnings on developer editions of their screen reader. The number of testers of NVDA alpha snapshots is below 2% and eating into that number is extremely likely to lead to more bugs in stable NVDA versions. Every single tester of alpha is important, so we catch bugs before the beta editions and can iterate early in the design. Catching bugs in beta is also important, and the number of beta testters is slightly higher even in beta. If addons break, or are found to break in an alpha or beta version, that often can give the developer of such addons weeks or months of time to fix the addon before it hits the api incompatible version, leading to a better experience for the whole product.

Join to automatically receive all group messages.