Package and publish

Publishing is a product and trust review, not only a ZIP upload.

Use a valid increasing version, polished icons, accurate feature copy, and screenshots of real behavior. Explain permissions and data use. Build from a clean checkout, exclude tests and secrets, submit through the store, and test the installed release before promoting it.

The ZIP root must contain manifest.json, not another project directory. Build a deterministic allowlist of runtime files rather than zipping the repository and trying to exclude mistakes. Inspect source maps, fixtures, environment files, private keys, unused permissions, remote-code patterns, and generated dependencies before upload.

The store listing and privacy declarations are part of the release. Describe the extension’s single purpose and actual behavior; screenshots must not promise features the package lacks. If code, assets, manifest, or data practices change, update the relevant package and dashboard metadata and submit the new version for review.

An accepted update is not maintenance completion. Existing users keep the previous release until the update publishes and installs, and added permissions can require user acceptance. Test the store-installed artifact in a clean profile, preserve a known-good package and release notes, monitor support and policy notices, and prepare a rollback path. Larger publishers may use staged rollout, but it does not replace pre-release testing.

Create a release checklist and reproducible ZIP whose root contains manifest.json. Compare its file list and hashes with the intended build output, install that exact package in a clean profile, upgrade from the prior version, and verify permissions, saved notes, store copy, privacy declarations, and rollback materials.