Maintain & grow

Shipping an update#

Open another pull request against the registry with the new sha. That is the entire 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 is a one-click update or a dialog, and both are worth designing around:

• A release that grows your manifest re-asks. A new route in permissions.sandbox, a new process, a new PATH entry or a badge you didn't have before turns a one-click update into a dialog that spells out every addition. Approval never transfers to powers the owner didn't approve.
• A manifest-identical change is still re-checked. It points at a new sha, so the registry's security gate reruns before that update appears in official discovery. Same code review bar, every release.

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.