Upgrading

Cheap Seats keeps your history across upgrades.

• Backups before schema changes. Before it changes an existing database’s schema, Cheap Seats copies it to cheapseats.db.bak-v<N> beside it. To roll back, stop Cheap Seats, put the copy back as cheapseats.db, and run the previous version.
• No running old on new. It refuses to start on a database from a newer version, rather than run an older one on it.
• Old runs stay useful. Runs recorded by earlier versions stay readable, comparable and retryable.
• Config changes come with a migration. When a release changes the config format, cheapseats check says what to change, and a cheapseats migrate-config step converts it. Upgrading the app before converting the config loses nothing: Cheap Seats links old results to prompts by their text once the converted config is in place.

With an image per config commit (see Deploying), upgrading Cheap Seats is a reviewed change to the FROM line in your config repo.

Upgrading to prompt ids

From a release before prompt ids: run cheapseats migrate-config on your config repo, review the generated ids, run cheapseats check, and commit; then deploy the new version.

cheapseats migrate-config [dir]           give each prompt an id, in sets written before ids

What a release can restart

A release that changes how answers are asked or graded starts trends over, and its release notes should say so. Anything else that changes is annotated on the rankings, not a new trend.

cheapseats version prints this build’s version and database schema; GET /api/version returns the version, config commit and database schema.