Extension

The extension ships manually to each browser's store. Separate listings, separate review queues.

Release checklist

1. Bump the version: ./bump-version.sh 1.2.0. Stores reject duplicate version numbers. Don't edit the manifests by hand — the version lives in seven files and the script updates all of them.
2. Build: ./build.sh
3. Upload Chrome: dist/web-reader-chrome.zip at the Chrome Web Store developer console.
4. Upload Firefox: dist/web-reader-firefox.xpi at addons.mozilla.org.
5. Build Safari (macOS only): convert dist/safari/ with xcrun safari-web-extension-converter, then build and submit from Xcode.
6. Submit for review. Mozilla returns a signed .xpi once approved; Chrome publishes directly after review. Reviews usually take a few days.

DEPLOYING.md in the repository is the same checklist written for someone who has never worked on the project.

Version numbers

bump-version.sh keeps all three manifests and the embed server on one version, so a given number means the same code everywhere. The stores each track their own published version, and they will drift while one is still in review — that is expected.

Use the ordinary rules: a fix is a patch bump, a new option is a minor bump, and removing or changing something people depend on is a major bump.

Updating store listing strings

Store metadata (name, summary, description) lives in _locales/en/messages.json, which is separate from the in-app translations in locales/resources.json. Edit it before uploading if you want translated listings.

Rolling back

Stores don't allow true downgrades. To roll back: restore the previous code, bump the version number upward, and resubmit. There is no way to un-publish a version and have users return to an older one automatically.

This is the main practical difference from the widget, which can be rolled back in minutes — see Embed Server.

Last updated 2026-08-18