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

derek riemer
 

That makes sense, I'm primarily concerned that users will have to manually update all addons every version, even if they literally didn't change. I think we should do the lastTested thing serverSide, or at least offer a mechanism to update that on the server eventually, so users don't need to download the exactt same payload with just a different tested version if that version is already tested..

On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

At least Add-on Updater enforces this check for now unless the strategy changes.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 4:26 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?

 

I really don't think the last tested bit should be enforced until we have an updator.

 

On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz <nrm1977@...> wrote:

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




--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com





--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




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

 

Hi,

The plan (which is really a separate thread at this point) involves sending current NVDA version, along with add-on names, their versions and update channel metadata. In return the client will get update info for add-ons deemed compatible based on the NVDA version sent to the server.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 5:34 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?

 

That makes sense, I'm primarily concerned that users will have to manually update all addons every version, even if they literally didn't change. I think we should do the lastTested thing serverSide, or at least offer a mechanism to update that on the server eventually, so users don't need to download the exactt same payload with just a different tested version if that version is already tested..

 

On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

At least Add-on Updater enforces this check for now unless the strategy changes.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 4:26 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?

 

I really don't think the last tested bit should be enforced until we have an updator.

 

On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz <nrm1977@...> wrote:

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



--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com



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

Noelia Ruiz
 

Regarding to the enforzement and the original question, I wass missing, until I shared the code here, that for NVDA the last tested version is always present and not an empty value, since it defaults to the current NVDA version when the manifest doesnt declare it. So the important think is that this doesnt break NVDA or system stability. If an author doesnt want to specify last tested version and the add-on is fully compatible, we cannot enforze this since user experience pass. But if alpha versions of NVDA or the last stable version is incompatible, since the test version is too low and the add-on will be blocked, or even worse, if the author doesnt specify a tested version and for this reason NVDA considers that the add-on is good but in fact it break things, review should fail and the ad-on shouldnt remain in the stable section of the website.
Other question would be, as suggested by Andy (not directly), clarify, in addons manager, the maximum version supported according to the last tested value, for instance: last test version: 2019.-3 (max suported version: 2019.-4 of course when available). Not sure if it would be needed.
Cheers


Enviado desde mi iPhone

El 30 sept 2019, a las 2:40, Joseph Lee <joseph.lee22590@...> escribió:

Hi,

The plan (which is really a separate thread at this point) involves sending current NVDA version, along with add-on names, their versions and update channel metadata. In return the client will get update info for add-ons deemed compatible based on the NVDA version sent to the server.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 5:34 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?

 

That makes sense, I'm primarily concerned that users will have to manually update all addons every version, even if they literally didn't change. I think we should do the lastTested thing serverSide, or at least offer a mechanism to update that on the server eventually, so users don't need to download the exactt same payload with just a different tested version if that version is already tested..

 

On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

At least Add-on Updater enforces this check for now unless the strategy changes.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 4:26 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?

 

I really don't think the last tested bit should be enforced until we have an updator.

 

On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz <nrm1977@...> wrote:

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



--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com



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

Andy B.
 

I think maximum NVDA version should be required because we are talking about a range of NVDA versions. It makes it clear to developers and users, if included in add-on manager, that this add-on supports the stated NVDA versions, even if they are alpha/beta builds. Now, when stating a nonexistent version of NVDA, such as alpha, beta, or threshold builds, maximum NVDA version should indicate an api version such as 2019.3, but also include a prerelease branch such as threshold, alpha, beta, or rc. After this, we would have versions stated such as minimumNVDAVersion = 2019.3-alpha, or maximumNVDAVersion = 2019.3-beta1.

 

Andy Borka

Accessibility Engineer

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Sunday, September 29, 2019 10:58 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?

 

Regarding to the enforzement and the original question, I wass missing, until I shared the code here, that for NVDA the last tested version is always present and not an empty value, since it defaults to the current NVDA version when the manifest doesnt declare it. So the important think is that this doesnt break NVDA or system stability. If an author doesnt want to specify last tested version and the add-on is fully compatible, we cannot enforze this since user experience pass. But if alpha versions of NVDA or the last stable version is incompatible, since the test version is too low and the add-on will be blocked, or even worse, if the author doesnt specify a tested version and for this reason NVDA considers that the add-on is good but in fact it break things, review should fail and the ad-on shouldnt remain in the stable section of the website.

Other question would be, as suggested by Andy (not directly), clarify, in addons manager, the maximum version supported according to the last tested value, for instance: last test version: 2019.-3 (max suported version: 2019.-4 of course when available). Not sure if it would be needed.

Cheers

 

Enviado desde mi iPhone


El 30 sept 2019, a las 2:40, Joseph Lee <joseph.lee22590@...> escribió:

Hi,

The plan (which is really a separate thread at this point) involves sending current NVDA version, along with add-on names, their versions and update channel metadata. In return the client will get update info for add-ons deemed compatible based on the NVDA version sent to the server.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 5:34 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?

 

That makes sense, I'm primarily concerned that users will have to manually update all addons every version, even if they literally didn't change. I think we should do the lastTested thing serverSide, or at least offer a mechanism to update that on the server eventually, so users don't need to download the exactt same payload with just a different tested version if that version is already tested..

 

On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

At least Add-on Updater enforces this check for now unless the strategy changes.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 4:26 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?

 

I really don't think the last tested bit should be enforced until we have an updator.

 

On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz <nrm1977@...> wrote:

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




--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com





--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




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

Andy B.
 

Either way, someone has to declare supported NVDA versions. Each add-on manifest will have to declare minimum NVDA version and maximum NVDA version. Otherwise, how is the server going to know what the compatible range for each add-on is?

 

 

Andy Borka

Accessibility Engineer

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Sunday, September 29, 2019 8:40 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?

 

Hi,

The plan (which is really a separate thread at this point) involves sending current NVDA version, along with add-on names, their versions and update channel metadata. In return the client will get update info for add-ons deemed compatible based on the NVDA version sent to the server.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 5:34 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?

 

That makes sense, I'm primarily concerned that users will have to manually update all addons every version, even if they literally didn't change. I think we should do the lastTested thing serverSide, or at least offer a mechanism to update that on the server eventually, so users don't need to download the exactt same payload with just a different tested version if that version is already tested..

 

On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

At least Add-on Updater enforces this check for now unless the strategy changes.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 4:26 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?

 

I really don't think the last tested bit should be enforced until we have an updator.

 

On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz <nrm1977@...> wrote:

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



--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com



--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com


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

Andy B.
 

Who tests the add-on against the stated NVDA version? The add-on owners, NVDA add-on community, or NVDA developers?

 

 

Andy Borka

Accessibility Engineer

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 8:34 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?

 

That makes sense, I'm primarily concerned that users will have to manually update all addons every version, even if they literally didn't change. I think we should do the lastTested thing serverSide, or at least offer a mechanism to update that on the server eventually, so users don't need to download the exactt same payload with just a different tested version if that version is already tested..

 

On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

At least Add-on Updater enforces this check for now unless the strategy changes.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 4:26 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?

 

I really don't think the last tested bit should be enforced until we have an updator.

 

On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz <nrm1977@...> wrote:

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



--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com



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

Andy B.
 

To remain consistent and reliable, it is better to change it, even if not required. Besides, NVDA developers can force a new api version at any time. Better to declare supported versions right away.


Andy Borka
Accessibility Engineer

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

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



















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

Andy B.
 

Thanks on the naming problem. We can educate the public, but keep in mind that the public's first impression of add-on development will come from looking at sources of the user's favorite add-ons. Since add-on developers might not include a comment in the manifest explaining last tested version, changing the name is useful.


Andy Borka
Accessibility Engineer

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Sunday, September 29, 2019 12:18 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?

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















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

Andy B.
 

Hi,

What happens if someone fails to look at the add-on template or the add-on development guide? The flag still needs a clear path of communication of its purpose. Changing the name does this.

Andy Borka
Accessibility Engineer

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

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


















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

Andy B.
 

The last tested version is a supported version because a developer will most likely not release an add-on with a nonexistent version of NVDA, or leave last tested version set to an NVDA version in which the add-on itself is broken. This might work for testers, but not for the general public. Understanding that minimum NVDA version and maximum NVDA version are the min/max NVDA versions the add-on supports or is built for, helps the user understand what he or she is getting into by installing this add-on.

Andy Borka
Accessibility Engineer

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















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

Andy B.
 

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


Andy Borka
Accessibility Engineer

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

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

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

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

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

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

Andy Borka
Accessibility Engineer

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

Imo the current name is right, since the latest tested version can be minor of the latest supported version. For example, you probably will not to update the tested version in the manifest for developer toolkit after when NVDA 2019.-4 is released, unless the api o NVDA has important deletions and NV Access incrennt the value for the bac compatibility.


Enviado desde mi iPhone

El 28 sept 2019, a las 17:53, Andy B. <sonfire11@...> escribió:

Why don't we change lastTestedNVDAVersion to maximumSupportedNVDABersion to align with the minimumSupportedNVDAVersion flag? The purpose is much more clearly stated and is self-documenting. After all, the last tested NVDA version is nothing more than the upper limit on what the add-on author is willing to support.


Andy Borka
Accessibility Engineer

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

Hi, imo, the expression used (last NVDA version tested) is right, since this is not speaking about specific versions of NVDA (nor last stable, nor beta or last master or future). Instead, this reflects what version has been tested. This may be a superold version of NVDA, and in this case, when you update to a version of NVDA not tested with an installed add-on, the add-on can be blocked so that it doesn't cause instability in the system.

Also, sometimes, for practical reasons, authors say that an add-on has been tested with the upcoming version of NVDA and NVDA allows it just for testing add-ons in development, so that they can be ready when the next stable version of NVDA is released.
Cheers


El 27/09/2019 a las 20:02, Travis Siegel escribió:
I'm still curious how the last tested version of a plugin can be for
a version that hasn't even been released yet.

I argued during the whole invention of this scheme that calling it
last tested version was a bad idea, but apparently, nobody payed
attention. I strongly urge that this parameter get a new name, since
it's impossible to test a nonexistent version for compatibility.
Call it expected compatible, or next release version or something,
but not last tested version, since there hasn't been any testing for
a release that doesn't exist. You're only confusing people.


On 9/26/2019 6:53 PM, Joseph Lee wrote:

Hi all,

Yesterday there was a discussion on NVDA add-ons list about Python 3
compatibility of add-ons and state of their manifests. While some
add-ons do declare 2019.3 as last tested version and are indeed
Python
3 ready, others such as Classic Selection is Python 3 ready from
source code level but not via the manifest. This is a point of
confusion because when installing such add-ons in NVDA 2019.3, NVDA
will say the add-on in question is incompatible.

Thus I would like to propose that when reviewing add-ons for
inclusion in community add-ons website, reviewers should perform
manifest checks. If an add-on does use features from a given release
yet the manifest says otherwise, authors should be notified and
corrections must be made before the add-on is included. In case of
an add-on declaring last tested version as something yet the source
code says something else, it still needs to be tested in the last
tested version (and newer) specified so the source code and the manifest is in sync.
This check also helps authors realize that they do need to update
their manifests from time to time to keep up with NVDA changes,
because ideally, reviewers should not be the ones telling authors to
update their manifests unless it is necessary to do so.

As for when to enforce compatibility range check (minimum version <=
current version <= last tested version), I propose January 1, 2020
as start date. This allows people to prepare for both NVDA 2019.3
and this check at the same time. As for what to do with add-ons that
does not include minimum and last tested version flags in their
manifests, I think a notice should be sent to authors so they can
take care of it as soon as possible, or if the author isn’t willing,
NVDA community should do it (for Classic Selection, it is Tyler
Spivey who should be contacted).

If this proposal is adopted by the community, I propose sending out
a notice about it several times:

* November 1, 2019: giving authors 60 days to change their
manifests
and do something about Python 3.
* One of the 2019.3 betas if NV Access agrees with this proposal.
* NVDA 2019.3 RC and stable release: to remind users about this
change if adopted.

Thanks.

Cheers,

Joseph










Beta builds, are they available

Brian's Mail list account
 

I have alpha updating. I have rc1 of 2019.2.1, and a beta build and some test builds and the stable, but beta is not updating, i see beta updates in the mail list and wondered if these are public available and if so why my beta is not updating to them.
could be my end which is why I ask.


Also can somebody remind me of how, on github to make it so I see my own posts and tickets in the email lists again? I thought I had fixed this but its gone back to hidden and I've forgotten how to allow them after all this time!!
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

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

Jason Meddaugh
 

When I look at Firefox, they don't disable every add-on whenever you do an update.

For some situations, such as switching to a new add-on system, they did flag old add-ons but there was a transition.

Now because of Python 3, there is a use case for old add-ons not working and users should be informed of this. But this is the exception and not the norm.

Currently, the update process for add-ons is very confusing for a new user. People are going to come to 2019.3, see that all of their add-ons won't work, and either get frustrated or abort the update. Nevermind that many of these add-ons that they are being told do not have updates really do have updates which just weren't downloaded yet.


If someone updates to 2019.3 and old add-ons are still listed, is the worst thing that could happen that some add-ons stop working? It's good to be out front and let the user know of this, but then where do they go? Users are being admonished and expected to read a statement, check a list of incompatible add-ons, check a box, and still have no solution to the problem.


I'm curious of what percentage of users have any add-ons installed. Is that a stat that is being tracked?


For my part, we will send an Email to any customer who bought a synth license from us at the appropriate time.


TLDR: Easy for devs and people here, but there are going to be a lot of user headaches and people who just will choose not to update.





Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798
On 9/27/2019 2:02 PM, Travis Siegel wrote:

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

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

Jason Meddaugh
 

Exactly, which is why add-ons shouldn't be disabled unless there is a good reason to do so. Python 3 is probably a good reason to do so but it shouldn't happen on every release, or devs will just set this flag to some version way in the future.




Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798

On 9/28/2019 2:26 PM, Travis Siegel wrote:
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










Important notice on add-on compatibility website: add-on additions and status changes due to manifest checks

 

Hi all,

 

A few days ago the NVDA community had a discussion about what is considered “compatible with NVDA 2019.3”. Based on comments from the community (namely considering manifest information in addition to source code), the following changes will be made to add-on compatibility announcements page:

 

  • Several add-ons released in recent days will be added – the good news is that most are Python 3/NVDA 2019.3 ready. In particular, David CM’s Beep Keyboard and Synth Ring Settings Selector are both Python 3 ready (source code and manifest).
  • Some add-ons with outdated manifest information will be marked “incompatible”. The most notable cases are Extended Winamp and Classic Selection. Although some of them are source code compatible, from users’ perspective, they are not because of outdated compatibility statements. Please update manifest info as soon as possible; if not, the community will exercise our option of maintaining those add-ons ourselves in the future.

 

Cheers,

Joseph

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

Luke Davis
 

I believe the Firefox case was raised by Jason earlier: how does Mozilla (or other software) handle addon compatibility enforcement and deprecation? I am reasonably sure all Firefox add-ons don't get updated every time Firefox does, but I am also sure that some add-ons do eventually get terminated by Firefox itself when they become known to be incompatible. But that is only my assumption about how it works, I don't actually know.

I dislike the idea that every time NVDA does a release, whether it changes the part of the API which an add-on relies on or not, the author has to pre-update the add-on. Even if that is just changing a value in the manifest, how many add-ons many people rely on today, would still be working if that was enforced now?

So I guess I agree with Noelia about last-tested's purpose.

I am wondering now if we might actually need two values:

1. An advisory value, that the author uses to specify "I only guarantee support up to this level of NVDA for this version of the add-on". That is a sort of soft max value, that doesn't actually keep later versions of NVDA from using the add-on by itself.
That would be what last-tested is supposedly doing now except in the case of 2019.3.
There are many reasons an author can't update an add-on right away upon a new NVDA release (or even a few of them, if they are "fast" point releases); and reasons a user may not be updating add-ons right away, especially given the current update framework.

NVDA itself could always be coded so that a version known to break the API, will make that soft "last tested" value into a hard "max compatibility" value on the fly, and refuse to run an add-on. But that should be rare, only happening in cases like this change to Python 3 and speech refactor.

2. The second value, is for when we know an add-on doesn't work with a future version of NVDA. A hard max compatibility version.
Of course, not all add-ons (perhaps not even most) should specify that, because they can't know what future version will break their code.
That is where I see a case for allowing administrators to update a manifest based on known broken add-ons to specify the max version.
But we definitely know that value now, for add-ons that only work up to the last Python 2 version of NVDA. Something like that could allow old and new add-on versions to exist in relative harmony.

Just an idea.

Luke

On Mon, 30 Sep 2019, Andy B. wrote:

The last tested version is a supported version because a developer will most likely not release an add-on with a nonexistent version of NVDA, or leave last tested version set to an NVDA version in which the add-on itself is broken. This might work for testers, but not for the general public. Understanding that minimum NVDA version and maximum NVDA version are the min/max NVDA versions the add-on supports or is built for, helps the user understand what he or she is getting into by installing this add-on.

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

Noelia Ruiz
 

Hi Luke and all:

I think that the meaning of the last tested version is documented, and if we read code and related issues and pull request can know that it's intended to avoid than authors need to update add-ons which can work well in the upcoming release of NVDA. In fact, the approach of api versions wass revised. Maybe useful an article in the NV Access wiki, though really for me this discussion is quite surprissing.
I would always recommend to specify last tested version and the other values of the manifest, as done by NV Access (I read it in the developer guide time ago). So we can be quite sure that add-ons don't break things if NVDA is updated. Also, if authors have time and availability, they can choose to update the last test version so that users can see it in the about button of the add-on. But imo this shouldn't be mandatory and is documented time ago.

Cheers

El 02/10/2019 a las 07:34, Luke Davis escribió:
I believe the Firefox case was raised by Jason earlier: how does Mozilla (or other software) handle addon compatibility enforcement and deprecation? I am reasonably sure all Firefox add-ons don't get updated every time Firefox does, but I am also sure that some add-ons do eventually get terminated by Firefox itself when they become known to be incompatible. But that is only my assumption about how it works, I don't actually know.
I dislike the idea that every time NVDA does a release, whether it changes the part of the API which an add-on relies on or not, the author has to pre-update the add-on. Even if that is just changing a value in the manifest, how many add-ons many people rely on today, would still be working if that was enforced now?
So I guess I agree with Noelia about last-tested's purpose.
I am wondering now if we might actually need two values:
1. An advisory value, that the author uses to specify "I only guarantee support up to this level of NVDA for this version of the add-on". That is a sort of soft max value, that doesn't actually keep later versions of NVDA from using the add-on by itself.
That would be what last-tested is supposedly doing now except in the case of 2019.3.
There are many reasons an author can't update an add-on right away upon a new NVDA release (or even a few of them, if they are "fast" point releases); and reasons a user may not be updating add-ons right away, especially given the current update framework.
NVDA itself could always be coded so that a version known to break the API, will make that soft "last tested" value into a hard "max compatibility" value on the fly, and refuse to run an add-on. But that should be rare, only happening in cases like this change to Python 3 and speech refactor.
2. The second value, is for when we know an add-on doesn't work with a future version of NVDA. A hard max compatibility version.
Of course, not all add-ons (perhaps not even most) should specify that, because they can't know what future version will break their code.
That is where I see a case for allowing administrators to update a manifest based on known broken add-ons to specify the max version.
But we definitely know that value now, for add-ons that only work up to the last Python 2 version of NVDA. Something like that could allow old and new add-on versions to exist in relative harmony.
Just an idea.
Luke
On Mon, 30 Sep 2019, Andy B. wrote:

The last tested version is a supported version because a developer will most likely not release an add-on with a nonexistent version of NVDA, or leave last tested version set to an NVDA version in which the add-on itself is broken. This might work for testers, but not for the general public. Understanding that minimum NVDA version and maximum NVDA version are the min/max NVDA versions the add-on supports or is built for, helps the user understand what he or she is getting into by installing this add-on.

Error when trying to update NVDA to 2019.2.1

Noelia Ruiz
 

Hi, thanks for fixing critical bugs in this version. I get this error:

ERROR - unhandled exception (10:35:03.559):
Traceback (most recent call last):
File "updateCheck.pyo", line 733, in onClose
File "updateCheck.pyo", line 417, in _download
File "updateCheck.pyo", line 553, in __init__
KeyError: 'apiVersion

Cheers

Re: Error when trying to update NVDA to 2019.2.1

 

This looks pretty severe. Could you please file a github issue for this along with steps to reproduce?

Re: Error when trying to update NVDA to 2019.2.1

Noelia Ruiz
 

Yes, I haven't been able to update on Windows 10 and no on Windows 7,
in both Windows versions, but on Windows 10 I haven't seen the log.


2019-10-02 11:02 GMT+02:00, Leonard de Ruijter <@leonardder>:

This looks pretty severe. Could you please file a github issue for this
along with steps to reproduce?