Re: [Nvda-devel] Add-on versioning feedback

[Reef T. <re...@nv...>]

Hi Joseph,


I think there are a few things getting confused here, to be clear I am
referring to the intended behaviour of our new proposal (#9055).

 there are up to three NVDA versions in circulation: stable, beta/RC, and
> alpha
>

True, but it's important to note that alpha builds are still in active
development and API changes may yet happen. I would not suggest
definitively stating that an addon is compatible with a version (and
updating the *last tested* value) until it reached beta stage. Once NVDA
gets to beta, then it is very unlikely that there will be API changes.

This may include add-on users testing 2019.1 beta, at which point NVDA may
> say the add-on is "incompatible" because last tested version is 2018.4.


For the majority of NVDA releases, add-on authors won't have to update any
flags to maintain compatibility. The only situation in which the addon will
need to be updated, is when NVDA moves the *backwards compatible to* forward
to a value higher than the addons *last tested *value.  This will not
happen often. Then the addon author needs to inspect NVDA's change log,
decide if the change is relevant to the addon, test the addon, and update
the *last tested* value to the version of NVDA they tested against.

You can force NVDA to "ignore" this by setting compatibility manually.


The user will not be able to override the incompatibility of the addon
using the NVDA GUI. The addon manifest must be updated.


> So when considering last tested version flag, the ideal case is setting
> the version to latest stable release, but since we have snapshot users who
> are actively testing various add-ons, you need to consider their needs,
> too.
>

This is correct, the *last tested* value should not ever be set to a value
that could not have been adequately tested yet. Instead it should be set to
the latest stable, RC / beta. However, it only needs to be updated if NVDA
drops support for the addon's existing *last tested* value, resulting in
the addon being considered incompatible by NVDA.

in which case they should be given an option to set the flag to latest
> publicly available snapshot release (and keep up with what's happening)


Mostly this should not be necessary, only for addons being newly developed
in parallel with features in NVDA, or when *backwards compatible to* is
moved forward to a value higher than the addon's last tested value.

In short, the whole point of what I'm trying to communicate is that
> authors should be willing to: test stable releases of NVDA, and never
> forget development snapshot users.


Yes, I think use cases around snapshot users hasn't been given the same
level of consideration, particularly those on alpha. However, for the most
part, these addons should rarely be rendered incompatible. During
development of something like speech refactor there isn't a clear solution
for ensuring that addons will not be disabled by NVDA for snapshot users.
Obviously, for addons that use speech.py this HAS to be the case, but for
those that don't it's a little trickier. Unfortunately we don't have a
componentized API which might give more control. Some of the work-arounds,
none of which I like very much might be:
- Set the *last tested* value to the alpha version. I don't like this
because it's essentially saying something not true, the alpha version is a
moving target. An addon author would have to testing and re-releasing their
addon almost constantly, and the users would have to installing the updates
too to avoid instability.
- Do nothing, accept that there may be (very few) releases where snapshot
builds are not compatible with addons.
- Have an advanced option for disabling the compatibility check for only
the currently being used pre-release NVDA version.

I don't think we need to solve this part of the problem immediately. The
majority of users (those using stable releases, wanting stable addons) are
well catered for.

On Thu, 13 Dec 2018 at 02:05, <jos...@gm...> wrote:

> Hi,
> Eh, 2018.4 alpha?
> Besides that, we need to consider that, at any given moment, there are up
> to
> three NVDA versions in circulation: stable, beta/RC, and alpha. What I
> meant
> to say is this:
> Suppose an add-on declares itself as compatible with 2018.4, thus it runs
> well in 2018.4 (or NVDA says it is compatible). Someone may come along and
> report that the add-on is working as advertised in 2019.1 alpha. You may
> choose to update the flag then, or wait until 2019.1 beta 1 ships, at which
> point more people are asked to try out new features. This may include
> add-on
> users testing 2019.1 beta, at which point NVDA may say the add-on is
> "incompatible" because last tested version is 2018.4. You can force NVDA to
> "ignore" this by setting compatibility manually. At some point, you may
> need
> to update last tested version to 2019.1 or any future version users are
> giving you feedback about.
> So when considering last tested version flag, the ideal case is setting the
> version to latest stable release, but since we have snapshot users who are
> actively testing various add-ons, you need to consider their needs, too.
> Ultimately, that flag is set by add-on developers, so I'd defer that to
> them. But I do see a need for a clearer guidelines, which may stipulate
> that
> authors must test add-ons with at least the latest available stable version
> and set the last tested version flag accordingly unless they're active
> snapshot users, in which case they should be given an option to set the
> flag
> to latest publicly available snapshot release (and keep up with what's
> happening). If this is adopted, depending on how they're testing NVDA,
> add-on authors should have a choice of setting last tested version to
> between 2018.3 and 2019.1 (as of right now, these are the release ranges in
> active circulation; note that 2019.1 is in alpha phase).
> One possible way to resolve this issue for snapshot users is to state that,
> for a test version of NVDA, if an add-on is marked as compatible to latest
> stable/beta/RC, it should work. For example, an add-on that is flagged as
> compatible with 2018.4 should be considered compatible in alpha snapshots
> of
> December 2018. Once 2019.1 transitions to beta status, add-ons marked for
> 2018.4 should stay compatible. This changes for alpha users once NVDA
> version (versionInfo module) is updated to 2019.2, at which point 2018.4
> era
> add-ons should be marked incompatible.
> In short, the whole point of what I'm trying to communicate is that authors
> should be willing to: test stable releases of NVDA, and never forget
> development snapshot users.
> Hope this helps.
> Cheers,
> Joseph
>

-- 
Regards,
Reef Turner