> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tappify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Releases, rolling updates, and release notes

> At most two releases exist at a time. Which one your publish becomes, and when review is involved.

An extension has at most two releases: the `live` one every install is serving, and one
other — waiting on review, withdrawn back to a draft, or rejected. Publishing overwrites
rather than accumulating, so there is no version to pick and nothing to promote. The version
a release is labelled with is your `package.json` version, read out of the bundle.

```bash theme={null}
tappify extension status
```

## What a publish becomes

| Situation                                                                                              | Result                                                                                                                                                                |
| ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `visibility: "private"`                                                                                | `live`, always. Private extensions are never reviewed, and the starter ships private, so a scaffolded extension's first publish is live in your own workspace at once |
| `visibility: "unlisted"`                                                                               | `live`. The release is opened for review and approved by the automated checks in the same request                                                                     |
| No live release yet, `visibility: "public"`                                                            | `in_review`. Every public first publish is read by a person before anyone outside your workspace can install                                                          |
| A live release, and the diff adds no scope and no contribution kind                                    | `live`. It replaces the live release now                                                                                                                              |
| A live release, and the diff adds a scope or a new kind of contribution                                | `in_review`. The live release keeps serving until a reviewer decides                                                                                                  |
| A live release, and the manifest widens visibility — private to unlisted or public, unlisted to public | `in_review`, on the same footing as a new scope                                                                                                                       |

"A new contribution kind" means a kind the live release does not have — your first widget,
your first action, your first storage collection. A second widget is not a new kind. The
seven assistant blocks count separately, so your first skill is a new kind even when you
already ship tools.

Dropping a scope or a contribution kind never sends a release to review.

## Release notes

```bash theme={null}
tappify extension publish --notes "Adds the cohort tab and drops the unused revenue scope"
```

At most 1,000 characters. Owners read them on the install's page in their dashboard; a
reviewer reads them first. They are stored on the release and on the timeline, so
"what changed in 0.4.0" has an answer after the fact.

## Withdrawing a pending release

A release in review can be pulled back to a draft from the Releases page in the developer
portal. The live release is untouched and the review timeline is kept. Publish again when you
are ready and it re-enters review. Publishing while a release is still in review replaces
that release rather than queueing a second one.

## What owners see

An approved release swaps into `live` and every install picks it up on its next load; the
host re-reads its installs about once a minute while the dashboard is open. When the new
release asks for a scope an owner has not granted, their install renders

```
Funnel Lab needs revenue:read on Photo Editor — the current release asks for a scope you haven't granted on this project.
```

with Review scopes and Keep current, and the rest of their dashboard is unaffected. Owner
admins are told once, when a release that widened the scope set goes live — after a reviewer
approves it, or when the automated checks approve an unlisted one. A private publish sends no
notice, so the card is the only signal there.

A rejected release is marked rejected on the Releases page with the reviewer's reason.
Nothing changes for owners.