Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?
Brian's Mail list account
Well I did say this at the time, but its hard to find a suitable replacement. I'd suggest that to muddy the water by saying this should work on xxx version is less committal than saying it will. I think that if it does not work, then the author hopefully will fix that as most of the big changes have already been made to cope with sound refactoring wx and python 3, so gotcha later on may well revolve around other more hard to predict stuff, which is what has been happening on and off in python 2 already, Remote add on remember?toggle quoted messageShow quoted text
I'm still not sure what is going on there.
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Travis Siegel" <tsiegel@...>
Sent: Friday, September 27, 2019 7:02 PM
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?
I'm still curious how the last tested version of a plugin can be for a
version that hasn't even been released yet.
I argued during the whole invention of this scheme that calling it last
tested version was a bad idea, but apparently, nobody payed attention. I
strongly urge that this parameter get a new name, since it's impossible
to test a nonexistent version for compatibility. Call it expected
compatible, or next release version or something, but not last tested
version, since there hasn't been any testing for a release that doesn't
exist. You're only confusing people.
On 9/26/2019 6:53 PM, Joseph Lee wrote: