Re: NVDA 2019.3


Reef Turner
 

Hi all,
The below quote from Joseph is indeed the reason that we won't update the version number. Due to the nature of this update, for many it is important to be able to identify that it is "that" version of NVDA. Changing the version number now would invalidate lots of already published material speaking about it. So while it's a little awkward that we are already into 2020, it's only a name with no real consequence of being called 2019.3.

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.
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io On Behalf Of Shaun Everiss
Sent: Wednesday, 8 January 2020 5:36 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] 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.