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

Andy B.

This brings up a point I am trying to make... New add-on developers may not have any idea where to look for the documentation on last tested version. The goal of any software is to be as self-documenting as possible. So far, NVDA miserably fails on this point, at least for new add-on developers. As I mentioned, users wanting to have a try at add-on development will get lost quickly, as I did at one time.
NVDA, like any software package offering an API, should be as self-documenting as possible. To do this, last tested version should get changed to maximum NVDA version. Then it is self-evident what the flag does.

Andy Borka
Accessibility Engineer

-----Original Message-----
From: <> On Behalf Of Noelia Ruiz
Sent: Wednesday, October 2, 2019 3:16 AM
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Hi Luke and all:

I think that the meaning of the last tested version is documented, and if we read code and related issues and pull request can know that it's intended to avoid than authors need to update add-ons which can work well in the upcoming release of NVDA. In fact, the approach of api versions wass revised. Maybe useful an article in the NV Access wiki, though really for me this discussion is quite surprissing.
I would always recommend to specify last tested version and the other values of the manifest, as done by NV Access (I read it in the developer guide time ago). So we can be quite sure that add-ons don't break things if NVDA is updated. Also, if authors have time and availability, they can choose to update the last test version so that users can see it in the about button of the add-on. But imo this shouldn't be mandatory and is documented time ago.


El 02/10/2019 a las 07:34, Luke Davis escribiรณ:
I believe the Firefox case was raised by Jason earlier: how does
Mozilla (or other software) handle addon compatibility enforcement and
deprecation? I am reasonably sure all Firefox add-ons don't get
updated every time Firefox does, but I am also sure that some add-ons
do eventually get terminated by Firefox itself when they become known
to be incompatible. But that is only my assumption about how it works,
I don't actually know.

I dislike the idea that every time NVDA does a release, whether it
changes the part of the API which an add-on relies on or not, the
author has to pre-update the add-on. Even if that is just changing a
value in the manifest, how many add-ons many people rely on today,
would still be working if that was enforced now?

So I guess I agree with Noelia about last-tested's purpose.

I am wondering now if we might actually need two values:

1. An advisory value, that the author uses to specify "I only
guarantee support up to this level of NVDA for this version of the
add-on". That is a sort of soft max value, that doesn't actually keep
later versions of NVDA from using the add-on by itself.
That would be what last-tested is supposedly doing now except in the
case of 2019.3.
There are many reasons an author can't update an add-on right away
upon a new NVDA release (or even a few of them, if they are "fast"
point releases); and reasons a user may not be updating add-ons right
away, especially given the current update framework.

NVDA itself could always be coded so that a version known to break the
API, will make that soft "last tested" value into a hard "max
compatibility" value on the fly, and refuse to run an add-on. But that
should be rare, only happening in cases like this change to Python 3
and speech refactor.

2. The second value, is for when we know an add-on doesn't work with a
future version of NVDA. A hard max compatibility version.
Of course, not all add-ons (perhaps not even most) should specify
that, because they can't know what future version will break their code.
That is where I see a case for allowing administrators to update a
manifest based on known broken add-ons to specify the max version.
But we definitely know that value now, for add-ons that only work up
to the last Python 2 version of NVDA. Something like that could allow
old and new add-on versions to exist in relative harmony.

Just an idea.


On Mon, 30 Sep 2019, Andy B. wrote:

The last tested version is a supported version because a developer
will most likely not release an add-on with a nonexistent version of
NVDA, or leave last tested version set to an NVDA version in which
the add-on itself is broken. This might work for testers, but not for
the general public. Understanding that minimum NVDA version and
maximum NVDA version are the min/max NVDA versions the add-on
supports or is built for, helps the user understand what he or she is
getting into by installing this add-on.

Join to automatically receive all group messages.