Four exports are deprecated and still present. Each is an alias that forwards
to its replacement with identical behaviour, so nothing breaks until the
removal — but new code should use the right-hand column.

| Deprecated | Use instead | Since | Notes |
| --- | --- | --- | --- |
| `ConnectUserMenu` | `ConnectUserButton` | 0.12 | It is one button that opens a modal; calling it a "menu" had people looking for a dropdown that never existed. `compact` maps to `variant="compact"`, the old default to `variant="inline"`. |
| `ConnectSideNav` | `ConnectSidebarNav` | 0.12 | The rail is a `ConnectSidebar` now, and its pieces are named after it. |
| `ConnectSideNavProps` | `ConnectSidebarNavProps` | 0.12 | The type half of the rename above. |
| `ConnectLogoProps.collapsed` | `variant="mark"` | 0.12 | A boolean that could only express two of the three lockups. `variant` wins when both are given. |

Each will go in a later minor, never without appearing here first.

## How deprecations work here

The SDK is `0.x`, and follows the convention that **minor versions may carry
breaking changes** while patch versions never do. That is not a licence to
break things quietly, so anything being removed goes through the same sequence:

<Steps>

<Step>
### Announced

It appears on this page and in [What's new](/docs/whats-new), with what
replaces it and why. A removal with no stated replacement is a bug in the
deprecation, not a shorter migration.
</Step>

<Step>
### Marked

The export carries a `@deprecated` JSDoc tag, so your editor strikes it through
and your build warns. That tag shows up in the [SDK reference](/docs/reference)
automatically — it is generated from the same comments.
</Step>

<Step>
### Removed

In a later minor, never the same one it was announced in. The changelog entry
names the version it was announced in, so a reader can tell how much notice
they had.
</Step>

</Steps>

## Reading a lifecycle

Pages describing something newer than the previous minor say so at the top.
When something is deprecated, its page says that instead, with a link here.

If a page carries no note, it describes current, supported behaviour.

## Already removed

Two things were removed before `0.10.0` and are worth naming, because
integrations written against early drafts may still reference them:

| Removed | Replacement | Why |
|---|---|---|
| `withConnect()` (Next config wrapper) | Nothing — delete the call | Its only job was asserting a `NEXT_PUBLIC_CONNECT_CLIENT_ID` that turned out to be unnecessary: the default sign-in flow bounces through your own `/signin`, which knows `client_id` server-side. Removed rather than left as a no-op. |
| `/sdk-docs`, `/application-docs` | [`/docs`](/docs) | Three documentation systems for one audience, each with its own navigation and search. Both are now generated into `/docs`; `/developers` redirects here. |

## Reporting

If something you depend on disappears without appearing here first, that is a
mistake worth telling us about — the sequence above is the contract, not an
aspiration.