You are viewing the documentation for a prerelease version. View Latest

NVDA Add-on Store submission and updates

Manifest fields enforced before release

The add-on’s manifest metadata is declared once, in buildVars.py’s `addon_info, and rendered into the packaged add-on via manifest.ini.tpl. tests/test_buildvars.py enforces these as repository release guardrails before a build is considered releasable — they are stricter than what the Store itself requires at submission time (see Submitting to the Add-on Store below for that form):

  • Required and non-empty: addon_name, addon_summary, addon_description, addon_version, addon_author, addon_url, addon_sourceURL, addon_minimumNVDAVersion, addon_lastTestedNVDAVersion, addon_license, addon_licenseURL.

  • addon_version must be strict three-part semver (major.minor.patch, integers only) — no -beta.N suffix; that suffix lives in the git tag only (see NVDA version compatibility for the version fields' own rules).

  • addon_name must be a lowercase, valid Python identifier — it also becomes the add-on’s install directory name. It’s pinned to dengjen_neural_voices.

  • addon_author must contain a bracketed email address.

  • addon_url, addon_sourceURL, addon_licenseURL must be https:// URLs with a domain.

Listing history

The add-on was renamed from Sonata Neural Voices to Dengjen Neural Voices in v4.0.0, at the original author’s request, as a condition of being listed in the NVDA Add-on Store — same add-on, same maintainer, same GPL v2 licence. tests/test_buildvars.py’s `TestAddonIdentity pins this so it can’t drift back: it asserts addon_name, addon_summary, both URL fields, and that the original author is credited first in addon_author.

Cutting a release

Releases are tag-driven from main:

  1. prepare-release.yml computes the next version from Conventional Commit subjects since the last tag (scripts/next-version.sh) and opens a chore: bump workspace version → X.Y.Z PR against buildVars.py.

  2. Merging that PR is the real release decision. release.yml tags the merge commit vX.Y.Z, which fires `build_addon.yml’s tag trigger.

  3. build_addon.yml builds the add-on, runs the test matrix on windows-latest and ubuntu-latest, then publishes a GitHub Release with the .nvda-addon file, the .pot translation template, and notes generated by gh release create --generate-notes with the artifact’s SHA256 appended.

The tag scheme accepts only vMAJOR.MINOR.PATCH or vMAJOR.MINOR.PATCH-beta.N — other prerelease labels such as -rc.N aren’t recognized by the release workflow’s tag check. Historical tags v3.2-beta.1 through v3.2-beta.4 used a non-standard two-part scheme and are left as published rather than renamed.

Submitting to the Add-on Store

After a release publishes, `build_addon.yml’s "Store submission summary" step writes two values to the workflow run’s job summary:

Field Value

Download URL

https://github.com/<repo>/releases/download/<tag>/<file>.nvda-addon

SHA256

the checksum of the published .nvda-addon file

Use those two values to fill in NVAccess’s registration form: https://github.com/nvaccess/addon-datastore/issues/new?template=registerAddon.yml.

This step runs identically on every release — there’s no separate "update" workflow in this repo. Re-submitting that same form with the new release’s Download URL and SHA256 is how an already-listed version gets updated in the store; the add-on’s own manifest version field is what lets the datastore tell the submission apart from the previous one.

Want to help? Learn how to contribute to the ZirekHQ docs ›