Allow addons to specify minimum compatible version of NVDA

[ctoth]

With the @script decorator and more upcoming changes that I hope to introduce to the addon system, it will be necessary for addons to specify what versions of NVDA they support so as to be able to alert users at installation time that their NVDA is not compatible.
I recommend a minimum_version key in the manifest.
Obviously this will not help existing versions of NVDA and addons, but the sooner we add it, the sooner it will be useful in future :)

[jcsteh]

Happy enough for this to be done. The reason this wasn't done initially is that snapshots present a problem, since the version string for snapshots is entirely different to the versioning for releases. However, #6205 introduces year/major/minor version attributes which can be used for this comparison.

[josephsl]

CC @derekriemer, @nvdaes, @jcsteh and other add-on writers.

[josephsl]

Hi,

Blocked by #6205.

Design:

1. For consistency reason, I propose calling it addon-minNVDAVersion or something short.
2. The manifest value will specify version string like year.major.minor. I think build should be optional, or if 0, it should specify that it is for stable NVDA versions.
3. The earliest opportunity to check for minimum version requirement is right before NVDA checks for existence of an earlier version of the add-on. I propose adding an error message if the requirement isn't met and abort, with a RuntimeError being generated and logged.
4. We need to talk to add-ons community in regards to readiness of some add-ons to test it (two or three add-ons should be selected as canaries).

Thanks.

[josephsl]

Hi,

Few issues and questions to consider:

• Rollback: user installs NVDA Y, then installs add-on A, then downgrades to NVDA X that makes the installed add-on incompatible, and suppose both X and Y use this feature. Should add-on handler recognize this and stop the incompatible add-on from running when NVDA starts?
• Disabled flag: suppose the above question is solved by doing a startup check, and the add-on is told to run. Is "suspended" the appropriate status for this add-on?

Thanks.

[nvdaes]

Hi, I'm thinking what happens with add-ons like a Word add-on, that
become "bad" since NVDA adds the same keystroke for features. Then,
should be the minVersion a needed field, instead of just a
possibility?
Advantages: This could prevent the ussage of obsolete add-ons.
Disadvantages: Some add-ons would need to be updated.
I think that NVDA should suspend add-ons whose min version is
incompatible. Then the user could search an updated version or see the
add-on help, uninstall or even enable the add-on for testing.
Thanks.

[LeonarddeR]

This has been abandoned for a little while now. Is someone intending to implement this?

[josephsl]

Hi, I’m tempted to label this for “good for new dev”. Thanks.

[michaelDCurran]

This is going to be an important bit of work for 2018.2 as so many large changes will be going in (wxPython 4, multi category settings, speech refactor). I think we should take the approach of Windows store, which is two values: minimumRequiredVersion, and lastVersionTested. Newer versions of NVDA can refuse to load add-ons if they have a lastVersionTested lower than the current version or it is missing. NVDA can also refuse to load add-ons with a minimRequiredVersion higher than the current version... though obviously this would not have an impact until at least 2018.3 actually existed.

[LeonarddeR]

I propose minimumNVDAVersion and lastTestedNVDAVersion in order not to create ambiguity with add-on version numbers itself. Both minimum and required is not scrtictly necessary I belief. Anyhow, I'm happy to take this issue.

[LeonarddeR]

While looking at the addonHandler code, I noticed that the Addon object has quite a few magic properties while not inheriting from AutoPropertyObject. Is there a particular reason for this?

[michaelDCurran]

I don't believe there is a good reason. Simply just history I guess. We tended to only use AutoPropertyObject for NVDAObjects / TextInfos (representations of content). We never considered using it for other arbitrary objects.

[jcsteh]

I also find myself wondering occasionally whether those `_get_foo` magic properties were really such a good idea. The problem with magic is that it's a barrier to entry and it's hard to work out where to document it because it's not explicit. Still, that's out of scope for this issue. :)