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















Robert Hänggi
 

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













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







 

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







Doug Lee
 

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







--
Doug Lee dgl@... http://www.dlee.org
Level Access doug.lee@... http://www.LevelAccess.com
"It is difficult to produce a television documentary that is both
incisive and probing when every twelve minutes one is interrupted by
dancing rabbits singing about toilet paper." --Rod Serling


 

Well I personally think we should just ditch 2019.3, and make it 2020.1.

Reason was 2019.3 was betaed basically in christmas, I know users were ready for this, but what is it going to do to the release schedual.

Either we become a release out, or quickly within a few months maybe when windows 20h1 goes golden nvda 2020.1 just to push the numbers up.

In the long term a release out is not a problem except well odd numbers but if it got more than that then users would wander if things were lagging behind.

I realise that this is a major upgrade the last one happened ages ago when we transitioned from the 1.0-2.0 type versions to the year versions.

I know before that we were on build numbers but still.

I would personally not feel cheated if the release of 2019.3 became 2020.1.

Saying that, using a month for a release say 2020.2 or whatever or .1 since its january could mean if you wanted to be incromental you could have many releases but different month numbers, obviously not all the time but still.

On 8/01/2020 4:09 pm, 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






 

Hmph.

To be honest, if all it is is a manafest issue, as I understand there is a minimum tested and whatever.

If this minimum is set to 2019.3 and the max can be any number, if I understand it, if it runs on 2019.3 then it would pass the check.

Its a bit dumb if this is the case, it is 2020 now.

On 8/01/2020 3:45 pm, Luke Davis wrote:
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



.


 

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


Luke Davis
 

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


Brian's Mail list account
 

Not being on the user list these days, I do hope this clear statement will be posted there when the new release goes out as stable, and is repeated, perhaps in the download install file to make sure people don't burn their bridges if they are relying on an add on that has no direct updated replacement.
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

----- Original Message -----
From: "Reef Turner" <reef@...>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 9:16 PM
Subject: Re: [nvda-addons] NVDA 2019.3


Reef from NV Access here. NVDA 2019.3 will not be renamed to 2020.1

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.
The oldest API version still supported can be checked by looking at
'BACK_COMPAT_TO' value in the addonAPIVersion.py file
(https://github.com/nvaccess/nvda/blob/master/source/addonAPIVersion.py)

At the moment this value is 2019.3 (due to Python 3 upgrade and Speech
refactor), currently we plan to delay any compatibility breaking changes.
Hopefully in the future further granularity can be introduced into the API
versioning system so that addons that do not touch changed areas of NVDA do
not need to be updated.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io On Behalf Of Nikita
Sent: Sunday, 5 January 2020 5:19 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA 2019.3

Hello!

Please tell me how it is planned to processing compatibility flags in the
manifest.ini?
For example, I am releasing an add-on with the lastTestedNVDAVersion =
2019.3.0.
What happens when NVDA version 2020.1.0 is released?
Will I have to update all add-ons with a single change in the manifest.ini,
and all users will need to reinstall this add-on?
And so every time?
What if my add-on is fully compatible, but I got hit by a bus?

Don't you think plain users should have more control over installing
add-ons? They should have the right to control the risk of incompatibility
without necessarily repackaging add-ons.
Any of us may no longer be alive tomorrow, and maybe the person who repacks
compatible add-ons will not appear.

Sincerely, Nikita.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Rui Fontes
Sent: Sunday, January 05, 2020 6:29 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA 2019.3

No. If it was renamed to 2020.1 all add-ons will need to reflect that in the
manifest.ini...
So, all efforts made to make add-ons compatible will be lost and all authors
will need to change manifest.ini and submit again the add-on to the official
repository...

Rui Fontes


-----Mensagem original-----
De: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Em
Nome De Brian's Mail list account via Groups.Io
Enviada: domingo, 5 de janeiro de 2020 09:12
Para: nvda-addons@nvda-addons.groups.io
Assunto: Re: [nvda-addons] NVDA 2019.3

Yes, I thought that as well, indeed it has to be that way.
At the moment nobody can tell.

Actually and being serious for a moment as we are now in 2020, is it going
to be renamed 2020.1?
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
----- Original Message -----
From: "Governor staten" <@Govsta>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:05 AM
Subject: Re: [nvda-addons] NVDA 2019.3


I don't know if you intended to do it this way. You made a little rhyme.



----------------------------------------------------------------------
--


On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before. I heard that quote years ago
and its true. You would rather they wait to release a version ready
than rush it out the door.

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *Teddy Bear Cute
*Sent:* Saturday, January 4, 2020 9:34 PM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* [nvda-addons] NVDA 2019.3

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.

















Brian's Mail list account
 

Yes that was my worry, but somebody needed to ask.
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

----- Original Message -----
From: "Rui Fontes" <rui.fontes@...>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:29 PM
Subject: Re: [nvda-addons] NVDA 2019.3


No. If it was renamed to 2020.1 all add-ons will need to reflect that in the
manifest.ini...
So, all efforts made to make add-ons compatible will be lost and all authors
will need to change manifest.ini and submit again the add-on to the official
repository...

Rui Fontes


-----Mensagem original-----
De: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Em
Nome De Brian's Mail list account via Groups.Io
Enviada: domingo, 5 de janeiro de 2020 09:12
Para: nvda-addons@nvda-addons.groups.io
Assunto: Re: [nvda-addons] NVDA 2019.3

Yes, I thought that as well, indeed it has to be that way.
At the moment nobody can tell.

Actually and being serious for a moment as we are now in 2020, is it going
to be renamed 2020.1?
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
----- Original Message -----
From: "Governor staten" <@Govsta>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:05 AM
Subject: Re: [nvda-addons] NVDA 2019.3


I don't know if you intended to do it this way. You made a little rhyme.



----------------------------------------------------------------------
--


On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before. I heard that quote years ago
and its true. You would rather they wait to release a version ready
than rush it out the door.

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *Teddy Bear Cute
*Sent:* Saturday, January 4, 2020 9:34 PM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* [nvda-addons] NVDA 2019.3

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.









Reef Turner
 

Reef from NV Access here. NVDA 2019.3 will not be renamed to 2020.1

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.
The oldest API version still supported can be checked by looking at
'BACK_COMPAT_TO' value in the addonAPIVersion.py file
(https://github.com/nvaccess/nvda/blob/master/source/addonAPIVersion.py)

At the moment this value is 2019.3 (due to Python 3 upgrade and Speech
refactor), currently we plan to delay any compatibility breaking changes.
Hopefully in the future further granularity can be introduced into the API
versioning system so that addons that do not touch changed areas of NVDA do
not need to be updated.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io On Behalf Of Nikita
Sent: Sunday, 5 January 2020 5:19 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA 2019.3

Hello!

Please tell me how it is planned to processing compatibility flags in the
manifest.ini?
For example, I am releasing an add-on with the lastTestedNVDAVersion =
2019.3.0.
What happens when NVDA version 2020.1.0 is released?
Will I have to update all add-ons with a single change in the manifest.ini,
and all users will need to reinstall this add-on?
And so every time?
What if my add-on is fully compatible, but I got hit by a bus?

Don't you think plain users should have more control over installing
add-ons? They should have the right to control the risk of incompatibility
without necessarily repackaging add-ons.
Any of us may no longer be alive tomorrow, and maybe the person who repacks
compatible add-ons will not appear.

Sincerely, Nikita.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Rui Fontes
Sent: Sunday, January 05, 2020 6:29 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA 2019.3

No. If it was renamed to 2020.1 all add-ons will need to reflect that in the
manifest.ini...
So, all efforts made to make add-ons compatible will be lost and all authors
will need to change manifest.ini and submit again the add-on to the official
repository...

Rui Fontes


-----Mensagem original-----
De: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Em
Nome De Brian's Mail list account via Groups.Io
Enviada: domingo, 5 de janeiro de 2020 09:12
Para: nvda-addons@nvda-addons.groups.io
Assunto: Re: [nvda-addons] NVDA 2019.3

Yes, I thought that as well, indeed it has to be that way.
At the moment nobody can tell.

Actually and being serious for a moment as we are now in 2020, is it going
to be renamed 2020.1?
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
----- Original Message -----
From: "Governor staten" <@Govsta>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:05 AM
Subject: Re: [nvda-addons] NVDA 2019.3


I don't know if you intended to do it this way. You made a little rhyme.



----------------------------------------------------------------------
--


On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before. I heard that quote years ago
and its true. You would rather they wait to release a version ready
than rush it out the door.

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *Teddy Bear Cute
*Sent:* Saturday, January 4, 2020 9:34 PM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* [nvda-addons] NVDA 2019.3

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.




Nikita
 

Hello!

Please tell me how it is planned to processing compatibility flags in the
manifest.ini?
For example, I am releasing an add-on with the lastTestedNVDAVersion =
2019.3.0.
What happens when NVDA version 2020.1.0 is released?
Will I have to update all add-ons with a single change in the manifest.ini,
and all users will need to reinstall this add-on?
And so every time?
What if my add-on is fully compatible, but I got hit by a bus?

Don't you think plain users should have more control over installing
add-ons? They should have the right to control the risk of incompatibility
without necessarily repackaging add-ons.
Any of us may no longer be alive tomorrow, and maybe the person who repacks
compatible add-ons will not appear.

Sincerely, Nikita.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Rui Fontes
Sent: Sunday, January 05, 2020 6:29 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA 2019.3

No. If it was renamed to 2020.1 all add-ons will need to reflect that in the
manifest.ini...
So, all efforts made to make add-ons compatible will be lost and all authors
will need to change manifest.ini and submit again the add-on to the official
repository...

Rui Fontes


-----Mensagem original-----
De: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Em
Nome De Brian's Mail list account via Groups.Io
Enviada: domingo, 5 de janeiro de 2020 09:12
Para: nvda-addons@nvda-addons.groups.io
Assunto: Re: [nvda-addons] NVDA 2019.3

Yes, I thought that as well, indeed it has to be that way.
At the moment nobody can tell.

Actually and being serious for a moment as we are now in 2020, is it going
to be renamed 2020.1?
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
----- Original Message -----
From: "Governor staten" <@Govsta>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:05 AM
Subject: Re: [nvda-addons] NVDA 2019.3


I don't know if you intended to do it this way. You made a little rhyme.



----------------------------------------------------------------------
--


On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before. I heard that quote years ago
and its true. You would rather they wait to release a version ready
than rush it out the door.

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *Teddy Bear Cute
*Sent:* Saturday, January 4, 2020 9:34 PM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* [nvda-addons] NVDA 2019.3

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.




Rui Fontes
 

No. If it was renamed to 2020.1 all add-ons will need to reflect that in the
manifest.ini...
So, all efforts made to make add-ons compatible will be lost and all authors
will need to change manifest.ini and submit again the add-on to the official
repository...

Rui Fontes


-----Mensagem original-----
De: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Em
Nome De Brian's Mail list account via Groups.Io
Enviada: domingo, 5 de janeiro de 2020 09:12
Para: nvda-addons@nvda-addons.groups.io
Assunto: Re: [nvda-addons] NVDA 2019.3

Yes, I thought that as well, indeed it has to be that way.
At the moment nobody can tell.

Actually and being serious for a moment as we are now in 2020, is it going
to be renamed 2020.1?
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

----- Original Message -----
From: "Governor staten" <@Govsta>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:05 AM
Subject: Re: [nvda-addons] NVDA 2019.3


I don't know if you intended to do it this way. You made a little rhyme.



----------------------------------------------------------------------
--


On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before. I heard that quote years ago
and its true. You would rather they wait to release a version ready
than rush it out the door.

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *Teddy Bear Cute
*Sent:* Saturday, January 4, 2020 9:34 PM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* [nvda-addons] NVDA 2019.3

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.




Dennis L <dennisl1982@...>
 

Lol I didn't.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Brian's Mail list account via Groups.Io
Sent: Sunday, January 5, 2020 4:12 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA 2019.3

Yes, I thought that as well, indeed it has to be that way.
At the moment nobody can tell.

Actually and being serious for a moment as we are now in 2020, is it going
to be renamed 2020.1?
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
----- Original Message -----
From: "Governor staten" <@Govsta>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:05 AM
Subject: Re: [nvda-addons] NVDA 2019.3


I don't know if you intended to do it this way. You made a little rhyme.



----------------------------------------------------------------------
--


On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before. I heard that quote years ago
and its true. You would rather they wait to release a version ready
than rush it out the door.

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *Teddy Bear Cute
*Sent:* Saturday, January 4, 2020 9:34 PM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* [nvda-addons] NVDA 2019.3

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.




Brian's Mail list account
 

Yes, I thought that as well, indeed it has to be that way.
At the moment nobody can tell.

Actually and being serious for a moment as we are now in 2020, is it going to be renamed 2020.1?
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

----- Original Message -----
From: "Governor staten" <@Govsta>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 3:05 AM
Subject: Re: [nvda-addons] NVDA 2019.3


I don't know if you intended to do it this way. You made a little rhyme.



------------------------------------------------------------------------


On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before. I heard that quote years ago
and its true. You would rather they wait to release a version ready
than rush it out the door.

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *Teddy Bear Cute
*Sent:* Saturday, January 4, 2020 9:34 PM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* [nvda-addons] NVDA 2019.3

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.



Teddy Bear Cute
 

Ok thanks for the info.

 

Daripada: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Bagi Pihak Joseph Lee
Hantar: Sunday, 5 January, 2020 10:35 AM
Kepada: nvda-addons@nvda-addons.groups.io
Subjek: Re: [nvda-addons] NVDA 2019.3

 

Hi,

For now, we don’t know.

Cheers,

Joseph


 

I don't know if you intended to do it this way. You made a little rhyme.





On 1/4/2020 9:36 PM, Dennis L wrote:

When its ready and not a moment before.  I heard that quote years ago and its true.  You would rather they wait to release a version ready than rush it out the door.

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Teddy Bear Cute
Sent: Saturday, January 4, 2020 9:34 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] NVDA 2019.3

 

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.


Dennis L <dennisl1982@...>
 

When its ready and not a moment before.  I heard that quote years ago and its true.  You would rather they wait to release a version ready than rush it out the door.

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Teddy Bear Cute
Sent: Saturday, January 4, 2020 9:34 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] NVDA 2019.3

 

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.


 

Hi,

For now, we don’t know.

Cheers,

Joseph

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Teddy Bear Cute
Sent: Saturday, January 4, 2020 6:34 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] NVDA 2019.3

 

Hi members, this is Mr. Tai from Penang Malaysia.

I want to ask, when the NVDA 2019.3 will be releace?

Hope can get the anser.