Overview
What to do when you move to a new release. One page per release that needs steps from you, newest first.
The releases
| Release | What you do |
|---|---|
| 0.22 | Event ids are unique per session. Postgres: apply the new schema.sql, then deploy. Redis: use a new keyPrefix. |
| 0.21 | Rewrite handlers as consumers. Let earlier deployments finish; on Postgres, then apply the new schema.sql. SQLite starts fresh. |
| 0.20 | Postgres: apply schema.sql yourself, before you deploy. |
| 0.19 | Start new agent sessions: earlier ones don't fold. |
| 0.18 | Move the AI SDK loop's options into harness. |
| 0.17 | Redis: use a fresh keyPrefix. Serve agents with agent(). |
Across several releases
Read every page between the release you run and the one you're moving to,
oldest first. Code changes add up: make each page's changes. Store steps
don't always: each release's schema.sql covers a database from any earlier
release, so a Postgres database needs only the newest one, applied the way the
newest page says, and one fresh Redis keyPrefix covers every release that
asks for one.
Everything else
Each release's changelog lists everything it changes, including what needs no
steps: CHANGELOG.md,
also in the package at node_modules/experimental-a2/CHANGELOG.md. Releases
before 0.17 are only there.