Topics

NVDA 2019.3


Chikodinaka mr. Oguledo
 

when will we see a nvda update. for the add ons to work I cant update
my addons for NVDA It is new nvda is old

On 1/8/20, Robert Hänggi <aarjay.robert@...> wrote:
Wasn't there something similar with JAWS 18 and JAWS 2018 (which would
have been version 19)?
Microsoft doesn't adhere to their versions either, you might receive
an update in November despite having a 9 (September) in the build
number.
Robert

On 08/01/2020, Reef Turner <reef@...> wrote:
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