Hope this can be adrressed soon. Though this flag could be used in a database of the server without touching add-on manifests.
toggle quoted messageShow quoted text
Anyway, I think that add-ons not compatible with the last stable version of NVDA should be only used for special and justified reasons. Since people should be encouraged to update NVDA.
Enviado desde mi iPhone
El 28 sept 2019, a las 22:14, Joseph Lee <@joslee> escribió:
The compatibility range flag will become important once people start implementing the server component of add-on updating facility in NVDA in the future.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Noelia Ruiz
Sent: Saturday, September 28, 2019 1:12 PM
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?
Personally, I think that setting a last tested version to a non inexistent version is just acceptable for add-ons under development, not stable.
For this reason, and for the fact that I prefer to wait for possible changes made in NVDA before releasing the beta version, I prefer not to release even development versions of my add-ons declaring them compatible with NVDA 2019.3 until beta versions of NVDA are released.
But I think that the name latst tested version is descriptible and precisse, and it is an internal metadata only show when we press the about button of add-ons in the add-on manager, like the add-on name.
This is not a flag, imo, intended to be known by users unless they decide to look the add-on metadata. This is to be use in NVDA as an internal flag.
El 28/09/2019 a las 20:26, Travis Siegel escribió:
Yeah, but the problem we're running into now, and no doubt in the
future it will get worse, is the fact that your latest tested version
flag defaults to the next release version. What happens when there's
a major change, (or even a minor one) that causes something to behave
differently. Setting the last tested version to a release that hasn't
happened yet is misinformation at best, and downright lying at worst.
if I'm a writer of an add-on, I sure wouldn't agree that my last
tested version is for one that hasn't happened yet, since I personally
haven't tested it on that version. You're mislabeling the flag, and
that needs to be fixed, since it's impossible to know for a fact that
your add on is compatible with a release that hasn't even happened yet.
On 9/28/2019 2:06 PM, Noelia Ruiz wrote:
Imo the current name is right, since the latest tested version can be
minor of the latest supported version. For example, you probably will
not to update the tested version in the manifest for developer
toolkit after when NVDA 2019.-4 is released, unless the api o NVDA
has important deletions and NV Access incrennt the value for the bac
Enviado desde mi iPhone
El 28 sept 2019, a las 17:53, Andy B. <sonfire11@...> escribió:
Why don't we change lastTestedNVDAVersion to
maximumSupportedNVDABersion to align with the
minimumSupportedNVDAVersion flag? The purpose is much more clearly
stated and is self-documenting. After all, the last tested NVDA
version is nothing more than the upper limit on what the add-on
author is willing to support.
From: email@example.com <firstname.lastname@example.org> On Behalf Of
Sent: Saturday, September 28, 2019 2:39 AM
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested
NVDA version flags for add-on reviews and certification upon 2019.3
Hi, imo, the expression used (last NVDA version tested) is right,
since this is not speaking about specific versions of NVDA (nor last
stable, nor beta or last master or future). Instead, this reflects
what version has been tested. This may be a superold version of
NVDA, and in this case, when you update to a version of NVDA not
tested with an installed add-on, the add-on can be blocked so that
it doesn't cause instability in the system.
Also, sometimes, for practical reasons, authors say that an add-on
has been tested with the upcoming version of NVDA and NVDA allows it
just for testing add-ons in development, so that they can be ready
when the next stable version of NVDA is released.
El 27/09/2019 a las 20:02, Travis Siegel escribió:
I'm still curious how the last tested version of a plugin can be
for a version that hasn't even been released yet.
I argued during the whole invention of this scheme that calling it
last tested version was a bad idea, but apparently, nobody payed
attention. I strongly urge that this parameter get a new name,
since it's impossible to test a nonexistent version for
compatibility. Call it expected compatible, or next release
version or something, but not last tested version, since there
hasn't been any testing for a release that doesn't exist. You're only confusing people.
On 9/26/2019 6:53 PM, Joseph Lee wrote:
Yesterday there was a discussion on NVDA add-ons list about Python
3 compatibility of add-ons and state of their manifests. While
some add-ons do declare 2019.3 as last tested version and are
3 ready, others such as Classic Selection is Python 3 ready from
source code level but not via the manifest. This is a point of
confusion because when installing such add-ons in NVDA 2019.3,
NVDA will say the add-on in question is incompatible.
Thus I would like to propose that when reviewing add-ons for
inclusion in community add-ons website, reviewers should perform
manifest checks. If an add-on does use features from a given
release yet the manifest says otherwise, authors should be
notified and corrections must be made before the add-on is
included. In case of an add-on declaring last tested version as
something yet the source code says something else, it still needs
to be tested in the last tested version (and newer) specified so
the source code and the manifest is in sync.
This check also helps authors realize that they do need to update
their manifests from time to time to keep up with NVDA changes,
because ideally, reviewers should not be the ones telling authors
to update their manifests unless it is necessary to do so.
As for when to enforce compatibility range check (minimum version
<= current version <= last tested version), I propose January 1,
2020 as start date. This allows people to prepare for both NVDA
2019.3 and this check at the same time. As for what to do with
add-ons that does not include minimum and last tested version
flags in their manifests, I think a notice should be sent to
authors so they can take care of it as soon as possible, or if the
author isn’t willing, NVDA community should do it (for Classic
Selection, it is Tyler Spivey who should be contacted).
If this proposal is adopted by the community, I propose sending
out a notice about it several times:
* November 1, 2019: giving authors 60 days to change their
and do something about Python 3.
* One of the 2019.3 betas if NV Access agrees with this proposal.
* NVDA 2019.3 RC and stable release: to remind users about this
change if adopted.