Upgrading

Install the new version and restart. A version that changes the database migrates it on the first start, and says so in the log. The changelog says what each version changed, including which ones migrate.

npm install -g @agentdeploymentco/bishop@latest

In a container, pull the new image and start it against the same volumes.

Rolling back

Bishop copies the database before it migrates. The copy lands in .bishop/backups/, named for the schema it holds. To go back, stop Bishop, install the version you were on, and restore it:

rm bishop.db bishop.db-wal bishop.db-shm
cp .bishop/backups/bishop.db.v8.backup bishop.db

Delete bishop.db-wal first, as above. Bishop runs the database in write-ahead logging mode, so recent changes live in that file rather than in bishop.db. A Bishop that stopped cleanly leaves nothing there, but one that was killed does, and SQLite replays it into whatever database file it finds beside it without checking that the two belong together. Restore without removing it and you get the migrated database back, looking exactly like a successful rollback. You can't tell which case you're in by looking, so remove them every time.

Nothing deletes the copies, and bishop gc leaves them alone. There's one per schema version this database has been migrated from, so a handful at most. Upgrading again from the same version replaces that version's copy, so if you restore, run the old version for a while and upgrade again, the copy covers that stretch too.

If Bishop can't take the copy it refuses to start and says nothing was migrated, which usually means the disk is full or something else is under that name. Nothing has changed at that point, so fix the reason and start again.

Teams

An upgrade that adds a Teams permission needs the app removed and installed again before the permission takes effect. See Microsoft Teams.