Maintain & grow
A listing starts a cycle. Ship a release, get checked again, keep your rank and, for premium extensions, earn again. This page covers release two and every one after it.
On this page(5 sections)
Shipping an update
Open another pull request against the registry with the new sha. That is the whole release process: the version in your manifest is what users see and the sha is what runs. Nothing is built or uploaded, so there is no artifact to get wrong, and if your repo carries the intentic-extension topic, the nightly scan opens the pull request for you, same as it did the first time.
# The whole release process:
# 1. push the new code
git push
# 2. open a pull request against the registry pointing at the new sha
# (or wait: the nightly topic scan opens it for you)When an update re-asks
Two rules decide whether your release lands as a one-click update or a dialog, and both are worth designing around:
| Your release | What the owner gets |
|---|---|
Grows the manifest: a new permissions.sandbox route, process, PATH entry or badge | A dialog that spells out every addition. Approval never transfers to powers the owner didn't approve. |
| Manifest-identical: same powers, new code | One click, but still re-checked: the security gate reruns on the new sha before the update reaches official discovery. |
Nothing auto-updates by default, and the one policy that does apply updates unattended requires your listing to be human-verified and your powers to have stayed the same. Both are things you earn rather than declare.
How your release is received
The owner sees an update badge, a diff of any new powers, the kept previous version and a one-click revert, and a health watch on what they're running. A release flagged as a security fix promotes the badge from ambient to loud, because there the version they already have is the dangerous one. The whole far end is on Install & manage extensions, and it is worth reading once from that side: it is the experience your release notes and your manifest diff produce.
Staying ranked
The gallery and in-app discovery rank verified listings first and order by stars within each tier: both facts read back off your source host nightly, never edited by hand. Three things keep a listing healthy in that ordering:
- Stay loadable. The nightly scan re-checks your manifest and bundle at the pinned commit; a card that stops loading says so in public until you fix it.
- Pursue verification. It is the one rank input that is a decision rather than a metric: Verification & trust says what it claims and how to get it.
- Don't go quiet on a problem. A listing that goes bad is blocked and its installers advisories-notified; the trust page covers how that unwinds and how a fixed sha returns.
Updates are the revenue cadence
For a premium listing, maintenance and revenue are the same motion. An install donates once; an update can donate again, at most once a month per install. So a maintained extension can earn up to twelve donations a year from every install it keeps, and an abandoned one earns exactly once. The cap is also the guard: shipping meaningless updates to farm the cadence is delisting grounds, stated on the row like every other trust decision. Earn explains the credits, split and public ledger.
Related pages
- Publish & registries: the first listing this page assumes you already have.
- Verification & trust: the rank input that is a decision, and what blocked means.
- Earn: the pool, the split, and the ledger your donations land on.