nvaccess / addon-datastore-transform Goto Github PK

When using a prerelease copy of NVDA (from source, alpha, beta, rc, or try builds) there is no available endpoint for add-on listings, resulting in an error. For prototype purposes, the version used has been hard coded see PR: Add-on store #13985

Endpoints are available for each of the transforms based on the set of available releases, however, by definition a pre-release version of NVDA is not going to be available in that list. Instead, a "latest" transform should be added.

Combining this 'latest' endpoint with: Allow 'dev' version of add-on
#40 ensures that all combinations of stable and pre-release are supported for both add-ons and NVDA:

Stable NVDA

NVDA has been released final and has been published as a release.
Stable NVDA builds will access the API version specific endpoint.

Stable add-on

This is the standard case. Stable add-ons are offered to users of stable NVDA as long as they are compatible.

Beta add-on

Allows add-on authors to target a stable NVDA release and get feedback from early adopter users before publishing add-on as stable.

Dev add-on

Not offered when to users of stable NVDA.

Pre-release NVDA

alpha, beta, rc, try, or dev builds
These builds will access the "latest" endpoint.

Stable add-on

Add-on is presented as long as the API backwards compatible to has not been updated in this version of NVDA.
This allows NVDA developers/testers using pre-release NVDA versions to use the add-ons they usually use.

Beta add-on

Add-on is presented as long as the API backwards compatible to has not been updated in this version of NVDA.
This allows NVDA developers/testers using pre-release NVDA versions to use the add-ons they usually use.

Dev add-on

A special add-on channel for developing add-ons against the newest unreleased additions to NVDA, or to stay up to date with compatibility breaking changes.

• "compatible" means add-ons are only to be offered if there is overlap in API support (I.E. manifest and supported API range suggests the add-on is expected to be compatible with NVDA).
• This means that source copies for old NVDA versions may not have compatible add-ons. This is another issue, which could be solved by accessing the API version specific endpoint for the NVDA version the source copy was going to become.

How should latest be created:

For add-on ID X, the first submission should be taken when the submissions are ordered by:

1. Last tested addon API: the most recently tested add-on API version should be preferred.
2. Addon-version number: later add-on version numbers should be preferred.
3. Stable > beta > dev : if an add-on author promotes a dev version to beta or stable, those should be preferred. Note the implicit (filesystem) constraint applied by the add-on datastore prevents two submissions that have equal ID and version number. This last ordering is only theoretical. If this raises the question of "why have a dev channel?", remember that it allows the validation step to API compatibility constraints.