---
title: Overview
description: 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](/upgrades/0-22) | Event ids are unique per session. Postgres: apply the new `schema.sql`, then deploy. Redis: use a new `keyPrefix`. |
| [0.21](/upgrades/0-21) | Rewrite handlers as consumers. Let earlier deployments finish; on Postgres, then apply the new `schema.sql`. SQLite starts fresh. |
| [0.20](/upgrades/0-20) | Postgres: apply `schema.sql` yourself, before you deploy. |
| [0.19](/upgrades/0-19) | Start new agent sessions: earlier ones don't fold. |
| [0.18](/upgrades/0-18) | Move the AI SDK loop's options into `harness`. |
| [0.17](/upgrades/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`](https://github.com/vercel-labs/a2/blob/main/packages/a2/CHANGELOG.md),
also in the package at `node_modules/experimental-a2/CHANGELOG.md`. Releases
before 0.17 are only there.