Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #addonrelease


 

Dear NVDA community,

 

Yes, Add-on Updater 19.02.2 is coming soon. But before going into that, a bit of an explanation regarding what will happen:

 

A few days ago NV Access people announced a revised approach to how NVDA will check for add-on compatibility. Previously, add-on authors were advised to specify minimum and last tested NVDA version in the form year.major (e.g. 2018.4). Any add-ons that didn’t come with these flags, especially those that lacked last tested flag, were considered incompatible. In contrast, the new approach will keep backward compatibility by having a base API version to which all add-ons are considered compatible with, and add-on authors advised to update minimum version flag when breaking changes are introduced.

 

At the same time, the compatibility range manifest style has changed. Previously ad-on authors were told to specify compatibility version in the form year.major. Now, authors must include minor release as well, so it becomes year.major.minor (e.g. 2018.4.0). For the most part, authors can leave the minor release as 0.

 

To enforce the new approach, starting from version 19.02.2, Add-on Updater will advise you to contact add-on authors and request for a re-release if compatibility flags do not comply with the newly revised format. For example, if an add-on update specifies 2018.4.0 as minimum NVDA version, Add-on Updater won’t complain; but if minimum NVDA version is 2018.4 (just year.major), Add-on Updater will warn you of this fact and refuse to update until a version of the add-on that does come with revised compatibility flag format is released.

 

A few things to note:

 

  • To give time for authors and users to communicate with each other regarding add-on compatibility checks, this new check will be enforced if and only if you are running any form of NVDA 2019.1 (alpha, beta, RC, stable).
  • This change will become permanent (as far as Add-on Updater is concerned) around the time NVDA 2019.1 release candidate (RC) is released.
  • For authors, you do not have to specify minor release as part of compatibility range statement (if your add-on requires NVDA 2018.4.0 in the manifest, you can just say that NVDA 2018.4 is required).

 

In addition to the change outlined above, Add-on Updater 19.02.2 will enable update checks for one or two add-ons approved for distribution on community add-ons website.

 

Thank you.

Cheers,

Joseph


Brian's Mail list account <bglists@...>
 

So are you going to pull all the add ons that do not comply on the release date of the next nvda version and put them into a special sub site where people who have the know how can adapt them or use them on older versions of nvda?
I can see confusion on the horizon when folk try to install add ons from the site but which will not install.

Also, it does not mean in fact that add ons that fail the test are not going to work. I have proved that recently by adding the manifest flags as detailed manually to quite a number of the add ons and have been running them in alpha snaps with no issues at all.


Is nnvda going to keep the ability to force install and enable incompatible add ons by the user at their own risk? Obviously when nvda next updates the question can be asked again, but it will mean there is more time for add ons to be adapted.
Also I assume that somebody will produce what might e seen as a quick and dirty guide to the main reasons for add ons not being compatible as development of nvda goes forward. It would also be nice to try to find out the last version of nvda to use is a given unsupported add on has to be used, say in a work situation.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Tuesday, February 05, 2019 5:40 AM
Subject: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #AddonRelease


Dear NVDA community,



Yes, Add-on Updater 19.02.2 is coming soon. But before going into that, a
bit of an explanation regarding what will happen:



A few days ago NV Access people announced a revised approach to how NVDA
will check for add-on compatibility. Previously, add-on authors were advised
to specify minimum and last tested NVDA version in the form year.major (e.g.
2018.4). Any add-ons that didn't come with these flags, especially those
that lacked last tested flag, were considered incompatible. In contrast, the
new approach will keep backward compatibility by having a base API version
to which all add-ons are considered compatible with, and add-on authors
advised to update minimum version flag when breaking changes are introduced.



At the same time, the compatibility range manifest style has changed.
Previously ad-on authors were told to specify compatibility version in the
form year.major. Now, authors must include minor release as well, so it
becomes year.major.minor (e.g. 2018.4.0). For the most part, authors can
leave the minor release as 0.



To enforce the new approach, starting from version 19.02.2, Add-on Updater
will advise you to contact add-on authors and request for a re-release if
compatibility flags do not comply with the newly revised format. For
example, if an add-on update specifies 2018.4.0 as minimum NVDA version,
Add-on Updater won't complain; but if minimum NVDA version is 2018.4 (just
year.major), Add-on Updater will warn you of this fact and refuse to update
until a version of the add-on that does come with revised compatibility flag
format is released.



A few things to note:



* To give time for authors and users to communicate with each other
regarding add-on compatibility checks, this new check will be enforced if
and only if you are running any form of NVDA 2019.1 (alpha, beta, RC,
stable).
* This change will become permanent (as far as Add-on Updater is
concerned) around the time NVDA 2019.1 release candidate (RC) is released.
* For authors, you do not have to specify minor release as part of
compatibility range statement (if your add-on requires NVDA 2018.4.0 in the
manifest, you can just say that NVDA 2018.4 is required).



In addition to the change outlined above, Add-on Updater 19.02.2 will enable
update checks for one or two add-ons approved for distribution on community
add-ons website.



Thank you.

Cheers,

Joseph




Brian's Mail list account <bglists@...>
 

Joseph.
In the latest download of stable, there are very few add ons that are allowed to be enabled. However only one is flagged at the start, indent nav.
All the others seem to have been disabled silently. It is a huge list of them which I use on a regular basis, and as I said in my last message. I'm considering disabling updates in the nvda main version and only having the latest stable as a portable version until or unless more add ons can be made to work.
Might I suggest that there is some form of test mode in nvda that allows people to toggle on incompatible add ons to see if they actually work?
I think this would ease things a lot. I do understand that in the end many will be seen to be incompatible, but I also feel that the lead time is far too short to get part time writers to fix them before this new version of nvda comes out.
People are not doing it as a job after all.
Anyone else care to offer some advice?

The crunch surely will come when python 3 is adopted completely. I do not know when that will be, but until then I see no reason for doing more than alerting people It would also be nice to see nvda produce a list of the add ons that look like they are going to be a no go one when the time comes. At present there seems no way other than to go to the manage add ons page and manually list the ones turned off.
I think its quite legitimate to stop add ons being installed if they don't work but not if they already exist as this is going to cause a lot fo aggro.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Tuesday, February 05, 2019 5:40 AM
Subject: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #AddonRelease


Dear NVDA community,



Yes, Add-on Updater 19.02.2 is coming soon. But before going into that, a
bit of an explanation regarding what will happen:



A few days ago NV Access people announced a revised approach to how NVDA
will check for add-on compatibility. Previously, add-on authors were advised
to specify minimum and last tested NVDA version in the form year.major (e.g.
2018.4). Any add-ons that didn't come with these flags, especially those
that lacked last tested flag, were considered incompatible. In contrast, the
new approach will keep backward compatibility by having a base API version
to which all add-ons are considered compatible with, and add-on authors
advised to update minimum version flag when breaking changes are introduced.



At the same time, the compatibility range manifest style has changed.
Previously ad-on authors were told to specify compatibility version in the
form year.major. Now, authors must include minor release as well, so it
becomes year.major.minor (e.g. 2018.4.0). For the most part, authors can
leave the minor release as 0.



To enforce the new approach, starting from version 19.02.2, Add-on Updater
will advise you to contact add-on authors and request for a re-release if
compatibility flags do not comply with the newly revised format. For
example, if an add-on update specifies 2018.4.0 as minimum NVDA version,
Add-on Updater won't complain; but if minimum NVDA version is 2018.4 (just
year.major), Add-on Updater will warn you of this fact and refuse to update
until a version of the add-on that does come with revised compatibility flag
format is released.



A few things to note:



* To give time for authors and users to communicate with each other
regarding add-on compatibility checks, this new check will be enforced if
and only if you are running any form of NVDA 2019.1 (alpha, beta, RC,
stable).
* This change will become permanent (as far as Add-on Updater is
concerned) around the time NVDA 2019.1 release candidate (RC) is released.
* For authors, you do not have to specify minor release as part of
compatibility range statement (if your add-on requires NVDA 2018.4.0 in the
manifest, you can just say that NVDA 2018.4 is required).



In addition to the change outlined above, Add-on Updater 19.02.2 will enable
update checks for one or two add-ons approved for distribution on community
add-ons website.



Thank you.

Cheers,

Joseph




Brian's Mail list account <bglists@...>
 

PS even toolbar explorer is disabled.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io>
To: <nvda@nvda.groups.io>
Sent: Tuesday, February 05, 2019 8:40 AM
Subject: Re: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #AddonRelease


So are you going to pull all the add ons that do not comply on the release date of the next nvda version and put them into a special sub site where people who have the know how can adapt them or use them on older versions of nvda?
I can see confusion on the horizon when folk try to install add ons from the site but which will not install.

Also, it does not mean in fact that add ons that fail the test are not going to work. I have proved that recently by adding the manifest flags as detailed manually to quite a number of the add ons and have been running them in alpha snaps with no issues at all.


Is nnvda going to keep the ability to force install and enable incompatible add ons by the user at their own risk? Obviously when nvda next updates the question can be asked again, but it will mean there is more time for add ons to be adapted.
Also I assume that somebody will produce what might e seen as a quick and dirty guide to the main reasons for add ons not being compatible as development of nvda goes forward. It would also be nice to try to find out the last version of nvda to use is a given unsupported add on has to be used, say in a work situation.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Tuesday, February 05, 2019 5:40 AM
Subject: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #AddonRelease


Dear NVDA community,



Yes, Add-on Updater 19.02.2 is coming soon. But before going into that, a
bit of an explanation regarding what will happen:



A few days ago NV Access people announced a revised approach to how NVDA
will check for add-on compatibility. Previously, add-on authors were advised
to specify minimum and last tested NVDA version in the form year.major (e.g.
2018.4). Any add-ons that didn't come with these flags, especially those
that lacked last tested flag, were considered incompatible. In contrast, the
new approach will keep backward compatibility by having a base API version
to which all add-ons are considered compatible with, and add-on authors
advised to update minimum version flag when breaking changes are introduced.



At the same time, the compatibility range manifest style has changed.
Previously ad-on authors were told to specify compatibility version in the
form year.major. Now, authors must include minor release as well, so it
becomes year.major.minor (e.g. 2018.4.0). For the most part, authors can
leave the minor release as 0.



To enforce the new approach, starting from version 19.02.2, Add-on Updater
will advise you to contact add-on authors and request for a re-release if
compatibility flags do not comply with the newly revised format. For
example, if an add-on update specifies 2018.4.0 as minimum NVDA version,
Add-on Updater won't complain; but if minimum NVDA version is 2018.4 (just
year.major), Add-on Updater will warn you of this fact and refuse to update
until a version of the add-on that does come with revised compatibility flag
format is released.



A few things to note:



* To give time for authors and users to communicate with each other
regarding add-on compatibility checks, this new check will be enforced if
and only if you are running any form of NVDA 2019.1 (alpha, beta, RC,
stable).
* This change will become permanent (as far as Add-on Updater is
concerned) around the time NVDA 2019.1 release candidate (RC) is released.
* For authors, you do not have to specify minor release as part of
compatibility range statement (if your add-on requires NVDA 2018.4.0 in the
manifest, you can just say that NVDA 2018.4 is required).



In addition to the change outlined above, Add-on Updater 19.02.2 will enable
update checks for one or two add-ons approved for distribution on community
add-ons website.



Thank you.

Cheers,

Joseph





 

Hi,
When we compare the behavior from last year, the new approach partially
reverses the deal we went through in January. That is, any add-on with no
compatibility flags whatsoever will continue to work and seen as compatible,
whereas those that ships with these flags will need to be modified. This is
bound to change, as new NVDA releases may break compatibility (intentionally
or unintentionally due to something else).
Cheers,
Joseph

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Tuesday, February 5, 2019 1:02 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory
update), enforcing three-part NVDA compatibility flags #AddonRelease

Joseph.
In the latest download of stable, there are very few add ons that are
allowed to be enabled. However only one is flagged at the start, indent nav.
All the others seem to have been disabled silently. It is a huge list of
them which I use on a regular basis, and as I said in my last message. I'm
considering disabling updates in the nvda main version and only having the
latest stable as a portable version until or unless more add ons can be made
to work.
Might I suggest that there is some form of test mode in nvda that allows
people to toggle on incompatible add ons to see if they actually work?
I think this would ease things a lot. I do understand that in the end many
will be seen to be incompatible, but I also feel that the lead time is far
too short to get part time writers to fix them before this new version of
nvda comes out.
People are not doing it as a job after all.
Anyone else care to offer some advice?

The crunch surely will come when python 3 is adopted completely. I do not
know when that will be, but until then I see no reason for doing more than
alerting people It would also be nice to see nvda produce a list of the add
ons that look like they are going to be a no go one when the time comes. At
present there seems no way other than to go to the manage add ons page and
manually list the ones turned off.
I think its quite legitimate to stop add ons being installed if they don't
work but not if they already exist as this is going to cause a lot fo aggro.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Tuesday, February 05, 2019 5:40 AM
Subject: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory
update), enforcing three-part NVDA compatibility flags #AddonRelease


Dear NVDA community,



Yes, Add-on Updater 19.02.2 is coming soon. But before going into
that, a bit of an explanation regarding what will happen:



A few days ago NV Access people announced a revised approach to how
NVDA will check for add-on compatibility. Previously, add-on authors
were advised to specify minimum and last tested NVDA version in the
form year.major (e.g.
2018.4). Any add-ons that didn't come with these flags, especially
those that lacked last tested flag, were considered incompatible. In
contrast, the new approach will keep backward compatibility by having
a base API version to which all add-ons are considered compatible
with, and add-on authors advised to update minimum version flag when
breaking changes are introduced.



At the same time, the compatibility range manifest style has changed.
Previously ad-on authors were told to specify compatibility version in
the form year.major. Now, authors must include minor release as well,
so it becomes year.major.minor (e.g. 2018.4.0). For the most part,
authors can leave the minor release as 0.



To enforce the new approach, starting from version 19.02.2, Add-on
Updater will advise you to contact add-on authors and request for a
re-release if compatibility flags do not comply with the newly revised
format. For example, if an add-on update specifies 2018.4.0 as minimum
NVDA version, Add-on Updater won't complain; but if minimum NVDA
version is 2018.4 (just year.major), Add-on Updater will warn you of
this fact and refuse to update until a version of the add-on that does
come with revised compatibility flag format is released.



A few things to note:



* To give time for authors and users to communicate with each other
regarding add-on compatibility checks, this new check will be enforced
if and only if you are running any form of NVDA 2019.1 (alpha, beta,
RC, stable).
* This change will become permanent (as far as Add-on Updater is
concerned) around the time NVDA 2019.1 release candidate (RC) is released.
* For authors, you do not have to specify minor release as part of
compatibility range statement (if your add-on requires NVDA 2018.4.0
in the manifest, you can just say that NVDA 2018.4 is required).



In addition to the change outlined above, Add-on Updater 19.02.2 will
enable update checks for one or two add-ons approved for distribution
on community add-ons website.



Thank you.

Cheers,

Joseph





Brian's Mail list account <bglists@...>
 

By stable in this context I mean the test builds in alpha which seem pretty reliable to me now at any rate. As I said the download this morning has turned off two thirds of my usable add ons Having run all of them now, I think one perhaps easy to arrange idea might be to allow nvda to save a list of its add ons, versions and which are currently disabled due to them not being correctly flagged.
I have just spent an hour updating the flags on each of them and seeing what actually happens when they are run on the latest alpha. The good news is all of them actually work. One which is supposed to be working is giving odd errors. IE focus Highlight.

inputCore.InputManager.executeGesture (15:20:01.243):
Input: kb(desktop):enter
DEBUG - editableText.EditableText._hasCaretMoved (15:20:01.292):
Caret move detected using bookmarks. Elapsed: 0 ms
ERROR - queueHandler.flushQueue (15:20:01.359):
Error in func update from eventQueue
Traceback (most recent call last):
File "queueHandler.pyc", line 53, in flushQueue
File "C:\nvda extra\userConfig\addons\focusHighlight\globalPlugins\focusHighlight.py", line 489, in update
File "C:\nvda extra\userConfig\addons\focusHighlight\globalPlugins\focusHighlight.py", line 393, in updateLocations
File "C:\nvda extra\userConfig\addons\focusHighlight\globalPlugins\focusHighlight.py", line 269, in updateFocusLocation
File "C:\nvda extra\userConfig\addons\focusHighlight\globalPlugins\focusHighlight.py", line 249, in locationAvailable
TypeError: object of type 'NoneType' has no len()
IO - inputCore.InputManager.executeGesture (15:20:01.506):
Input: kb(desktop):space
IO - speech._speakSpellingGen (15:20:01.536):
Speaking character u'space'
DEBUG - queueHandler.registerGeneratorObject (15:20:01.536):
Adding generator 3446
DEBUG - queueHandler.pumpAll (15:20:01.559):
generator 3446 finished
IO - inputCore.InputManager.executeGesture (15:20:04.154):

However no effect of this is known to me as I normally only enable it when sighted people are here.
The other one is the 3D sound add on which is still giving the odd warning about the sntax etc.
Most of the others dev or stable seems to be doing what they always did.
Incidentally what is the meaning ofupdatechannel = none or stable?


I can see that the only change in add ons that already carried the correct flags but no longerr apparently do is a .x subversion flag in the manifest entries.

Could this not be assumed to be OK without the sub version if those flags make sense? Otherwise a lot of them will need a simple but time wasting tweak by authors.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io>
To: <nvda@nvda.groups.io>
Sent: Tuesday, February 05, 2019 9:01 AM
Subject: Re: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #AddonRelease


Joseph.
In the latest download of stable, there are very few add ons that are allowed to be enabled. However only one is flagged at the start, indent nav.
All the others seem to have been disabled silently. It is a huge list of them which I use on a regular basis, and as I said in my last message. I'm considering disabling updates in the nvda main version and only having the latest stable as a portable version until or unless more add ons can be made to work.
Might I suggest that there is some form of test mode in nvda that allows people to toggle on incompatible add ons to see if they actually work?
I think this would ease things a lot. I do understand that in the end many will be seen to be incompatible, but I also feel that the lead time is far too short to get part time writers to fix them before this new version of nvda comes out.
People are not doing it as a job after all.
Anyone else care to offer some advice?

The crunch surely will come when python 3 is adopted completely. I do not know when that will be, but until then I see no reason for doing more than alerting people It would also be nice to see nvda produce a list of the add ons that look like they are going to be a no go one when the time comes. At present there seems no way other than to go to the manage add ons page and manually list the ones turned off.
I think its quite legitimate to stop add ons being installed if they don't work but not if they already exist as this is going to cause a lot fo aggro.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Tuesday, February 05, 2019 5:40 AM
Subject: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #AddonRelease


Dear NVDA community,



Yes, Add-on Updater 19.02.2 is coming soon. But before going into that, a
bit of an explanation regarding what will happen:



A few days ago NV Access people announced a revised approach to how NVDA
will check for add-on compatibility. Previously, add-on authors were advised
to specify minimum and last tested NVDA version in the form year.major (e.g.
2018.4). Any add-ons that didn't come with these flags, especially those
that lacked last tested flag, were considered incompatible. In contrast, the
new approach will keep backward compatibility by having a base API version
to which all add-ons are considered compatible with, and add-on authors
advised to update minimum version flag when breaking changes are introduced.



At the same time, the compatibility range manifest style has changed.
Previously ad-on authors were told to specify compatibility version in the
form year.major. Now, authors must include minor release as well, so it
becomes year.major.minor (e.g. 2018.4.0). For the most part, authors can
leave the minor release as 0.



To enforce the new approach, starting from version 19.02.2, Add-on Updater
will advise you to contact add-on authors and request for a re-release if
compatibility flags do not comply with the newly revised format. For
example, if an add-on update specifies 2018.4.0 as minimum NVDA version,
Add-on Updater won't complain; but if minimum NVDA version is 2018.4 (just
year.major), Add-on Updater will warn you of this fact and refuse to update
until a version of the add-on that does come with revised compatibility flag
format is released.



A few things to note:



* To give time for authors and users to communicate with each other
regarding add-on compatibility checks, this new check will be enforced if
and only if you are running any form of NVDA 2019.1 (alpha, beta, RC,
stable).
* This change will become permanent (as far as Add-on Updater is
concerned) around the time NVDA 2019.1 release candidate (RC) is released.
* For authors, you do not have to specify minor release as part of
compatibility range statement (if your add-on requires NVDA 2018.4.0 in the
manifest, you can just say that NVDA 2018.4 is required).



In addition to the change outlined above, Add-on Updater 19.02.2 will enable
update checks for one or two add-ons approved for distribution on community
add-ons website.



Thank you.

Cheers,

Joseph





Brian's Mail list account <bglists@...>
 

That explains why some are working but did not before but some are not which did.
You know, my brain is hurting already.. How about others?
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: <nvda@nvda.groups.io>
Sent: Tuesday, February 05, 2019 9:48 AM
Subject: Re: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory update), enforcing three-part NVDA compatibility flags #AddonRelease


Hi,
When we compare the behavior from last year, the new approach partially
reverses the deal we went through in January. That is, any add-on with no
compatibility flags whatsoever will continue to work and seen as compatible,
whereas those that ships with these flags will need to be modified. This is
bound to change, as new NVDA releases may break compatibility (intentionally
or unintentionally due to something else).
Cheers,
Joseph

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Tuesday, February 5, 2019 1:02 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory
update), enforcing three-part NVDA compatibility flags #AddonRelease

Joseph.
In the latest download of stable, there are very few add ons that are
allowed to be enabled. However only one is flagged at the start, indent nav.
All the others seem to have been disabled silently. It is a huge list of
them which I use on a regular basis, and as I said in my last message. I'm
considering disabling updates in the nvda main version and only having the
latest stable as a portable version until or unless more add ons can be made
to work.
Might I suggest that there is some form of test mode in nvda that allows
people to toggle on incompatible add ons to see if they actually work?
I think this would ease things a lot. I do understand that in the end many
will be seen to be incompatible, but I also feel that the lead time is far
too short to get part time writers to fix them before this new version of
nvda comes out.
People are not doing it as a job after all.
Anyone else care to offer some advice?

The crunch surely will come when python 3 is adopted completely. I do not
know when that will be, but until then I see no reason for doing more than
alerting people It would also be nice to see nvda produce a list of the add
ons that look like they are going to be a no go one when the time comes. At
present there seems no way other than to go to the manage add ons page and
manually list the ones turned off.
I think its quite legitimate to stop add ons being installed if they don't
work but not if they already exist as this is going to cause a lot fo aggro.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Tuesday, February 05, 2019 5:40 AM
Subject: [nvda] Add-on Updater 19.02.2 coming soon (another mandatory
update), enforcing three-part NVDA compatibility flags #AddonRelease


Dear NVDA community,



Yes, Add-on Updater 19.02.2 is coming soon. But before going into
that, a bit of an explanation regarding what will happen:



A few days ago NV Access people announced a revised approach to how
NVDA will check for add-on compatibility. Previously, add-on authors
were advised to specify minimum and last tested NVDA version in the
form year.major (e.g.
2018.4). Any add-ons that didn't come with these flags, especially
those that lacked last tested flag, were considered incompatible. In
contrast, the new approach will keep backward compatibility by having
a base API version to which all add-ons are considered compatible
with, and add-on authors advised to update minimum version flag when
breaking changes are introduced.



At the same time, the compatibility range manifest style has changed.
Previously ad-on authors were told to specify compatibility version in
the form year.major. Now, authors must include minor release as well,
so it becomes year.major.minor (e.g. 2018.4.0). For the most part,
authors can leave the minor release as 0.



To enforce the new approach, starting from version 19.02.2, Add-on
Updater will advise you to contact add-on authors and request for a
re-release if compatibility flags do not comply with the newly revised
format. For example, if an add-on update specifies 2018.4.0 as minimum
NVDA version, Add-on Updater won't complain; but if minimum NVDA
version is 2018.4 (just year.major), Add-on Updater will warn you of
this fact and refuse to update until a version of the add-on that does
come with revised compatibility flag format is released.



A few things to note:



* To give time for authors and users to communicate with each other
regarding add-on compatibility checks, this new check will be enforced
if and only if you are running any form of NVDA 2019.1 (alpha, beta,
RC, stable).
* This change will become permanent (as far as Add-on Updater is
concerned) around the time NVDA 2019.1 release candidate (RC) is released.
* For authors, you do not have to specify minor release as part of
compatibility range statement (if your add-on requires NVDA 2018.4.0
in the manifest, you can just say that NVDA 2018.4 is required).



In addition to the change outlined above, Add-on Updater 19.02.2 will
enable update checks for one or two add-ons approved for distribution
on community add-ons website.



Thank you.

Cheers,

Joseph