Topics

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

 

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

Noelia Ruiz
 

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

Brian's Mail list account
 

OK I do think you are right here. On e has to draw a line in the sand at some point or it gets confusing, not only to users, but those building add ons. I also do agree that if a fix is simply a couple of lines of source and the manifest, if the author has not fixed it and somebody has made it work, it should be possible for that version to be added as an unofficial dev version for testing and if it seems stable and works the modifier can be added to the author list and the add on declared stable. Not all authors are still around of course, since life is like that and it would be a great shame if functions in some of these add ons are lost just because a couple of lines of source and a manifest tweak are needed. Obviously, very complex add ons such as the pesky 3D sounds one, are probably beyond the scope of 'simple fix' solutions. grin.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Thursday, September 26, 2019 11:53 PM
Subject: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?


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



Andy B.
 

Try and keep the technical stuff away from the typical user. As you said, they could care less, or not understand anything about Python. They just want something that works without problems.


Andy Borka
Accessibility Engineer

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




Travis Siegel
 

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


Virus-free. www.avast.com

Noelia Ruiz
 

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

Brian's Mail list account
 

Well I did say this at the time, but its hard to find a suitable replacement. I'd suggest that to muddy the water by saying this should work on xxx version is less committal than saying it will. I think that if it does not work, then the author hopefully will fix that as most of the big changes have already been made to cope with sound refactoring wx and python 3, so gotcha later on may well revolve around other more hard to predict stuff, which is what has been happening on and off in python 2 already, Remote add on remember?
I'm still not sure what is going on there.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Travis Siegel" <tsiegel@...>
To: <nvda-devel@groups.io>
Sent: Friday, September 27, 2019 7:02 PM
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?


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

Andy B.
 

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





Noelia Ruiz
 

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










Travis Siegel
 

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








Noelia Ruiz
 

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.

Cheers

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









 

Hi,
The compatibility range flag will become important once people start implementing the server component of add-on updating facility in NVDA in the future.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, September 28, 2019 1:12 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?

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.

Cheers


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











Noelia Ruiz
 

Hope this can be adrressed soon. Though this flag could be used in a database of the server without touching add-on manifests.
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.
Cheers


Enviado desde mi iPhone

El 28 sept 2019, a las 22:14, Joseph Lee <@joslee> escribió:

Hi,
The compatibility range flag will become important once people start implementing the server component of add-on updating facility in NVDA in the future.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, September 28, 2019 1:12 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?

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.

Cheers


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















Andy B.
 

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










 

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










Noelia Ruiz
 

Hi, if you want to build versions for testers you have to change the last tested version in the case of NVDA 2019.3 due to deletions in the API, but probably, when NVDA 2019.4 pre-releases or stable are published, you will not need to change the last tested version. So, the purpose of this field in the manifest maybe clarified in the add-on template, but for me the name is right since this doesn't mean the maximum version that the add-on is intended to support, nor the last version of NVDA beingbuild, nor the last stable.
Cheers

El 29/09/2019 a las 14:02, Andy B. escribió:
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










Noelia Ruiz
 

Anyway, if the glag is not changed (imo shouldn't be), you may explain it in the add-on template and in your developer guide (if needed). At least in the add-on template you may clarify that this is not the same as the last supported NVDA version.
Here's part of the code, which reviewers and authors may want to know for convenience:def isAddonTested(addon, backwardsCompatToVersion=addonAPIVersion.BACK_COMPAT_TO):
"""True if this add-on is tested for the given API version.
By default, the current version of NVDA is evaluated.
"""
return addon.lastTestedNVDAVersion >= backwardsCompatToVersion


def isAddonCompatible(
addon,
currentAPIVersion=addonAPIVersion.CURRENT,
backwardsCompatToVersion=addonAPIVersion.BACK_COMPAT_TO
):
"""Tests if the addon is compatible.
The compatibility is defined by having the required features in NVDA, and by having been tested / built against
an API version that is still supported by this version of NVDA.
"""
return hasAddonGotRequiredSupport(addon, currentAPIVersion) and isAddonTested(addon, backwardsCompatToVersion)


def isAddonTested(addon, backwardsCompatToVersion=addonAPIVersion.BACK_COMPAT_TO):
"""True if this add-on is tested for the given API version.
By default, the current version of NVDA is evaluated.
"""
return addon.lastTestedNVDAVersion >= backwardsCompatToVersion
def isAddonCompatible(
addon,
currentAPIVersion=addonAPIVersion.CURRENT,
backwardsCompatToVersion=addonAPIVersion.BACK_COMPAT_TO
):
"""Tests if the addon is compatible.
The compatibility is defined by having the required features in NVDA, and by having been tested / built against
an API version that is still supported by this version of NVDA.
"""
return hasAddonGotRequiredSupport(addon, currentAPIVersion) and isAddonTested(addon, backwardsCompatToVersion)

El 29/09/2019 a las 17:01, Joseph Lee escribió:
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










 

Hi,
Actually, you do need to change last tested version once 2019.4 comes out too, because that's how add-ons manager will check for compatibility (some folks found out the hard way when attempting to install an add-on that wasn't marked for 2019.3). The purpose of that flag is for add-on authors to communicate that they did test their add-ons in a specific NVDA release (or a development snapshot for it), and ideally, source code should match what the manifest claims. By doing so, it reminds authors that they do need to keep up with changes introduced in NVDA Core - the minimum flag won't change much, but last tested flag will from time to time.
As for communicating the purpose of that flag to users: I can see confusion. Calling it "last tested version" when in fact it specifies maximum compatible version isn't a good communication to begin with, because latest compatible and last tested versions are likely to be different (for my add-ons at least, they are really the same, although in public documentation I always specify latest stable version for maximum compatibility range because things under development can change rapidly; but then again, for my add-ons, I release development snapshots for some add-ons to keep up with alpha changes, or as Eric Raymond once advised, "release early, release often"). I think what can help might be to listening to public definition of this flag, and if they are not in line with the actual purpose of it, to educate users as to what it actually means; if there is indeed difference, perhaps come up with a compromise or think about this flag again in a few months.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Sunday, September 29, 2019 8:54 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 you want to build versions for testers you have to change the last tested version in the case of NVDA 2019.3 due to deletions in the API, but probably, when NVDA 2019.4 pre-releases or stable are published, you will not need to change the last tested version. So, the purpose of this field in the manifest maybe clarified in the add-on template, but for me the name is right since this doesn't mean the maximum version that the add-on is intended to support, nor the last version of NVDA beingbuild, nor the last stable.
Cheers


El 29/09/2019 a las 14:02, Andy B. escribió:
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















Noelia Ruiz
 

El 29/09/2019 a las 18:18, Joseph Lee escribió:
Hi,
Actually, you do need to change last tested version once 2019.4 comes out too, because that's how add-ons manager will check for compatibility

I think this is not right (if I'm wrong I will apologize :)
The add-ons manager (or NVDA doesn't check for compatibility directly looking at last tested version, but to the api containing the last tested version. This is a way to let authors precissely not to change this flag each time NVDA has a new stable release. So, when NVDA 2019.4 is out, we don't need to change this flag unless NVDA has important changes. NVDA 2019.3 is an exception due to Python 3 version and speech refactor.
But generally this flag, if used, don't need to be changed.

Cheers



El 29/09/2019 a las 18:18, Joseph Lee escribió:
Hi,
Actually, you do need to change last tested version once 2019.4 comes out too, because that's how add-ons manager will check for compatibility (some folks found out the hard way when attempting to install an add-on that wasn't marked for 2019.3). The purpose of that flag is for add-on authors to communicate that they did test their add-ons in a specific NVDA release (or a development snapshot for it), and ideally, source code should match what the manifest claims. By doing so, it reminds authors that they do need to keep up with changes introduced in NVDA Core - the minimum flag won't change much, but last tested flag will from time to time.
As for communicating the purpose of that flag to users: I can see confusion. Calling it "last tested version" when in fact it specifies maximum compatible version isn't a good communication to begin with, because latest compatible and last tested versions are likely to be different (for my add-ons at least, they are really the same, although in public documentation I always specify latest stable version for maximum compatibility range because things under development can change rapidly; but then again, for my add-ons, I release development snapshots for some add-ons to keep up with alpha changes, or as Eric Raymond once advised, "release early, release often"). I think what can help might be to listening to public definition of this flag, and if they are not in line with the actual purpose of it, to educate users as to what it actually means; if there is indeed difference, perhaps come up with a compromise or think about this flag again in a few months.
Cheers,
Joseph
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Sunday, September 29, 2019 8:54 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 you want to build versions for testers you have to change the last tested version in the case of NVDA 2019.3 due to deletions in the API, but probably, when NVDA 2019.4 pre-releases or stable are published, you will not need to change the last tested version. So, the purpose of this field in the manifest maybe clarified in the add-on template, but for me the name is right since this doesn't mean the maximum version that the add-on is intended to support, nor the last version of NVDA beingbuild, nor the last stable.
Cheers
El 29/09/2019 a las 14:02, Andy B. escribió:
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















Noelia Ruiz
 

I wanted to find this issue with many clarifications.
https://github.com/nvaccess/nvda/issues/9055

El 29/09/2019 a las 18:28, Noelia Ruiz via Groups.Io escribió:
El 29/09/2019 a las 18:18, Joseph Lee escribió:
Hi,
Actually, you do need to change last tested version once 2019.4 comes out too, because that's how add-ons manager will check for compatibility
I think this is not right (if I'm wrong I will apologize :)
The add-ons manager (or NVDA doesn't check for compatibility directly looking at last tested version, but to the api containing the last tested version. This is a way to let authors precissely not to change this flag each time NVDA has a new stable release. So, when NVDA 2019.4 is out, we don't need to change this flag unless NVDA has important changes. NVDA 2019.3 is an exception due to Python 3 version and speech refactor.
But generally this flag, if used, don't need to be changed.
Cheers
El 29/09/2019 a las 18:18, Joseph Lee escribió:
Hi,
Actually, you do need to change last tested version once 2019.4 comes out too, because that's how add-ons manager will check for compatibility (some folks found out the hard way when attempting to install an add-on that wasn't marked for 2019.3). The purpose of that flag is for add-on authors to communicate that they did test their add-ons in a specific NVDA release (or a development snapshot for it), and ideally, source code should match what the manifest claims. By doing so, it reminds authors that they do need to keep up with changes introduced in NVDA Core - the minimum flag won't change much, but last tested flag will from time to time.
As for communicating the purpose of that flag to users: I can see confusion. Calling it "last tested version" when in fact it specifies maximum compatible version isn't a good communication to begin with, because latest compatible and last tested versions are likely to be different (for my add-ons at least, they are really the same, although in public documentation I always specify latest stable version for maximum compatibility range because things under development can change rapidly; but then again, for my add-ons, I release development snapshots for some add-ons to keep up with alpha changes, or as Eric Raymond once advised, "release early, release often"). I think what can help might be to listening to public definition of this flag, and if they are not in line with the actual purpose of it, to educate users as to what it actually means; if there is indeed difference, perhaps come up with a compromise or think about this flag again in a few months.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Sunday, September 29, 2019 8:54 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 you want to build versions for testers you have to change the last tested version in the case of NVDA 2019.3 due to deletions in the API, but probably, when NVDA 2019.4 pre-releases or stable are published, you will not need to change the last tested version. So, the purpose of this field in the manifest maybe clarified in the add-on template, but for me the name is right since this doesn't mean the maximum version that the add-on is intended to support, nor the last version of NVDA beingbuild, nor the last stable.
Cheers


El 29/09/2019 a las 14:02, Andy B. escribió:
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