Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?
If we do this, the naming of flags is important. Since last tested versiontoggle quoted messageShow quoted text
only checks an API version (how confusing is that?), it should be changed to
something more relevant. Last API version would make sense, but only if we
made use of min/max NVDA versions.
Minimum NVDA version: minimum version of NVDA the add-on will run against.
Anything lower will not work.
Maximum NVDA version: Maximum version of NVDA the add-on will run against.
Anything higher is not guaranteed.
Last tested API: The last API version the add-on was tested against. Useful
for development builds or testing. This is a soft limit not enforced by
NVDA, but only a guideline on the add-on's progress if the developer wishes
to make the statement.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Luke Davis
Sent: Wednesday, October 2, 2019 1:35 AM
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA
version flags for add-on reviews and certification upon 2019.3 release?
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
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 developeradd-on itself is broken.
This might work for testers, but not for the general public.add-on.