Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Revised approach to addon compatibility #9055
This issue aims to discuss a revised approach to addon compatibility.
Issues with the existing Addon versioning checks
Consider the following situations:
The following use cases can be derived:
Addon API background
An addon specifies its window of compatibility with two manifest values, and will be considered compatible if the following are all True:
A more in depth look at these properties:
NVDA specifies a window for the API versions in (a new file)
When the two windows of compatibility overlap, then the add-on is considered compatible and can be enabled. For the ease of discussion, we will assume API version values are consecutive integers, however the exact scheme used for API version values will be discussed later. Consider an installation of NVDA 2020.2, with current API version of 6 and backwards compatible to API version 3:
First version with addon version checks
Release 2019.1 with add-on version check ASAP
Addon API Version Value Scheme
So far, we have used strings formatted as NVDA version strings for addon API version values. This caused difficulty when pulling the NVDA version string from the file information in the launcher executable because of the presence of other information. We have decided to ignore the minor part when considering whether an addon has been tested.
With regards to decoupling:
Alternatives to NVDA version string:
My preference is to use the tuple representation.
Changes to the UX
When there is an incompatibility, we would no longer state merely that the addon is untested and allow the user to override the incompatibility state. Instead, we will warn that it is incompatible, and the addon will be disabled after installation. The user should always be able to abort the installation.
One improvement could be to specifically detect and highlight incompatible addons that are providing the active synth / braille display. Since these are considered critical to the user.
Addon publishing platforms
Those responsible for addon publishing platforms and reviewing the addons contained there-in should note the importance of the accuracy of the last tested addon manifest value. If it is set to as-yet undeveloped future API versions, it will likely result in instability and reflect badly on the add-on publishing platform and those who reviewed the addon.
Thanks for this extensive write-down!
This is very unlikely to happen.
Note that we would still have to parse a string within updateCheck.checkForUpdate. Alternatively, the update server should return json data for versions of NVDA that support it.
I believe that configobj can parse them quite will. a definition would look like:
That basically means the following:
Apart from that, I think that the gui wording and experience is pretty ok as it is now. Thus, I propose keeping the "I understand that these add-ons will be disabled" checkboxes, etc.
This makes sense, and is pretty straight forward when the add-on is running:
In my case, this only applies to the speech synthesizer.
Yes, but I'm not so worried about this, since we can be strict about the formatting of this. Unlike the version string coming from the executable's file info.
I'm happy for the definitions to remain as strings in the addon manifest, and parse them with regex as we currently do. I suggest that we strictly validate that there are 3 numbers provided.