Re: NVDA 2019.3


 

Hmmph I never thought about it that way.

On 8/01/2020 5:31 pm, Doug Lee wrote:
In case it's useful to anyone, I actually think it a marvelous coincidence that we have 2019.3, emphasis on 3, be the first time we use Python 3. This is where I got my #nvda3 hashtag for my Twitter posts about add-on test
versions for this new NVDA incarnation.

On Tue, Jan 07, 2020 at 07:09:00PM -0800, Joseph Lee wrote:
Hi,
There are two flags to specify compatibility range: minimum API version (the
one Reef is talking about), and last tested version, the upper range I
mentioned briefly. The former signifies the minimum guaranteed NVDA version
an add-on is designed to run on, and is subject to change from NVDA side
based on work that went into a specific release (an add-on author can
specify a specific minimum version). The last tested version flag is used to
tell users the latest NVDA version the author has used to test the add-on.
As long as there is a minimum API version set and the last tested version
covers this API version, add-on is deemed compatible (obviously the true
extent of compatibility cannot be seen until one looks at code and uses
add-ons). However if the compatibility range does not include the current
minimum API version (say, the minimum API is 2020.2 and compatibility range
is between 2018.4 and 2020.1), add-on installation is blocked. The gray area
then is an add-on that claims to cover the minimum API version but turns out
it doesn't even use code optimized for later NVDA releases, or somehow it
doesn't work with the version marked as "last tested version".
In reality, you can change year.major.minor to anything and install an
add-on provided that the minimum API version is covered in the compatibility
range (to test this, I changed year.major to 2020.1 and tried to install an
add-on with minimum and last tested versions set to 2018.4 and 2019.3,
respectively, and NVDA presented typical installation dialog). People are
right in that, at this time of year, calling the upcoming release "2020.1"
is more appropriate (at least to keep with release schedule). At the moment,
however, all the marketing literature (including what's new document, blog
posts and what not) specifies 2019.3, and this was accepted by users. In
reality add-on authors don't have to change compatibility range statements
in their add-on manifests, but once the version is changed, it will create
confusion for users, especially when there is a beta version out there that
users are starting to discover.
Hope this makes sense.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Luke Davis
Sent: Tuesday, January 7, 2020 6:46 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA 2019.3

On Sun, 5 Jan 2020, Reef Turner wrote:

Nikita, to address your concerns. Addons do not need to update their
compatibility flags until an API breaking change is introduced into NVDA.
This will not happen every release. When it does happen the
'addonApiVersion.py' will be updated.
Forgive me for being thick-headed, but doesn't that invalidate the argument
made against updating the version number to 2020.1?

The argument that has been posted to the user list and here, has been that
add-on authors would have to update their compatibility flags to 2020.1, and
so all the work done to get manifests ready for 2019.3 would be invalidated.

But if what you said in answer to Nikita's question is true, then that
argument is not particularly valid since add-ons manifested to be compatible
with 2019.3, would still work with 2020.1.

I am obviously missing a piece here.

Luke






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