-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Thursday, September 26, 2019 11:50 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?

As mentioned, in this discussion for me is clear that the webpage should talk about compatibility with NVDA 2019.3, or something like that, prioritizing the purpose of the informative webpage, which could serve to inform if a particular add-on will work as expected if users update NVDA 2019.2 to 2019.3.
Users may not know about Python versions or other changes in the api like speech refactor. This is useful for devs and reviewers, not for other users.
About planning times, imo add-ons should be updated before NVDA 2019.3 stable is released, sho users can update NVDA without issues. This is important for NVDa development and even donations to NV Access, since some people may be used to donate when stable versions are released (personally I try to do so generally).
Also, we can try to enforze or talk to authors about dates, but it's up to them to follow our recommendations. We can just admin the website.
This is my opinion.
Cheers


El 27/09/2019 a las 00:53, Joseph Lee escribió:

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