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

Andy B.
 

Taking time is OK, as long as the initiative is widely documented and published.


Andy Borka
Accessibility Engineer

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Sunday, September 29, 2019 11:01 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Hi,
If the community and NV Access decide to change the last tested flag, it'll require time to test and document changes so add-on authors can prepare for it, similar to the initial version of the compatibility range flags.
Let's hear from NV Access people to see what they think.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Andy B.
Sent: Sunday, September 29, 2019 5:02 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Well, not really. If I want to release add-on builds for testers, I have to set the last tested version flag to the current prerelease of NVDA. This isn't a problem, but the flag's name is misleading at best. Minimum version and maximum version as I mentioned before, are self-documenting flags. There is no confusion that you have to run at least NVDA 2019.1.1, and nothing later than 2019.3 for this add-on to work.
Keep in mind that prospective add-on authors will take a look at some of their favorite add-on's manifest and source if they are interested in trying add-on development. Doing this makes sense because the user is already familiar with how the add-on works, so they can follow along with their experience while looking at the source. Unless a user is already somewhat buried in NVDA development, minimum version makes sense, but last tested version does not. Therefore, last tested version should be changed to maximum version with a comment in the manifest that maximum version is either equal to or greater than minimum version, and that maximum version may include prerelease versions of NVDA.

# The lowest supported version of NVDA.
minimumNVDAVersion = 2019.1.1 # DTK does not support 2019.1 because it was initially created during 2019.1.1 release.
maximumNVDAVersion = 2019.3 # The current alpha prelease cycle.

I vote to have the flags changed to represent the above example.

Andy Borka
Accessibility Engineer

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, September 28, 2019 2:06 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

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 compatibility.


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.


Andy Borka
Accessibility Engineer

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia
Ruiz
Sent: Saturday, September 28, 2019 2:39 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

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.
Cheers


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:

Hi all,

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 indeed
Python
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
manifests
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.

Thanks.

Cheers,

Joseph










Join nvda-devel@groups.io to automatically receive all group messages.