Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.
toggle quoted message. . .
The compatibility flag warning is a necessary stepping stone for two things that’ll have massive impact in our community: Python 3 and speech refactor. My position is that giving folks this warning early should let authors think about what to do and act accordingly.
As for incorporating some add-on features into NVDA Core: some might work, others won’t. At the moment my highest priority (besides studying for fall term finals and keeping an eye on Windows 10 updates) is Add-on Updater and incorporating that into NVDA.
As for NV Access taking over unmaintained add-ons: this depends on add-ons and surrounding copyright issues for some popular ones. For Vocalizer and friends, NV Access must reach out to Nuance about licensing and work with Code Factory and others regarding license transfer and what not. Unfortunately, there are speech synthesizers that won’t make the cut to Python 3 unless changes are made from authors, and it isn’t easy to contact authors for some to begin with.
As for advertising minimum and last tested NVDA versions for add-ons: I’d leave it up to authors to do this (both from manifest and on readme). Rest assured that my add-ons will ship with compatibility flags for future NVDA releases (both minimum and last tested versions defined and mentioned in the manifest and readme); this is the real reason for releasing version 18.12 of several of my add-ons: to prepare for what happened yesterday where compatibility flags are required. I’ll write up a more detailed announcement about compatibility flags for my add-ons later today.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Adriani Botez
thanks for forwarding this. However, then we should start working to adjust the add-on webpage so that the date of last update for an add-on is shown. The users could then decide much better if they install that add-on or not. But in my view this warning is a bit exagerated because some add-ons which are really useful are not regularly maintained by their original developers (i.e. audio theme 3d or even remote add-on where we see big delays in updating it). If NV Access really want to discourage users to use add-ons which are not updated regularly, then I think we should think about integrating useful functions into NVDA’s core. I mean functions from add-ons which are not maintained reliably. Because an add-on which is not maintained regularly does not mean that the add-on is not used by many users. Vocalizer for example is also not maintained regularly but, at least in Germany, about 60% of users use that add-on also at work. They would never change to eSpeak.
That’s why I think a survey worldwide would give us an orientation of which add-ons are used most often and whe can see which are regularly maintained and which not. After assessing the survey data NV Access can decide to overtake the add-ons which are abandoned or not updated for a very long time and integrate similar functions in NVDA.
But in long term we have to find a sustainable solution. Some statistics on the add-ons webpage would make this much easier (i.e. number of downloads for an add-on, last update and so on).
Hi NVDA community,
Please read the following announcement from Reef Turner, one of the lead developers of NVDA. Although his announcement won’t have any impact on many of you now, the change he has outlined will show up for NVDA 2019.1.
In order to address some looming issues that will affect the stability of add-ons in future releases (speech refactor, Python 3), a new add-on compatibility mechanism has been introduced. The short version is that add-ons will need to be updated more regularly. For a seamless user experience add-ons should be tested against each new NVDA release, excluding minor releases, and updated. The first Beta would be a good choice to confirm the add-on will work as expected with the release. Users will be strongly discouraged from installing, or leaving enabled, add-ons that have not followed this process.
For all the gritty details, see the pull request #8006