Upgrade and rollback

Upgrade

1. Read all relevant GitHub Releases between the installed version and target version.
2. Create an external, verified backup.
3. Change only the pinned image tag, pull the image, and restart the service.
4. Verify health, logs, sign-in, dashboard, inventory, and a known completed snapshot.

docker compose pull app
docker compose up -d app
docker compose ps
docker compose logs --tail=100 app

The documentation on main describes the latest application state. Changesets align the application version, Git tag, GitHub release, and image tag. Historical source documentation remains available in docs/ at each tag.

The future v1 migration-history baseline is a special case: do not point it directly at a v0 database after the legacy migrations are removed. Create a current .ezprint-backup first and use the documented v1 legacy importer. The v1 release is not complete until the retained synthetic v0 backup fixtures pass their restore tests.

Roll back

An image-only rollback is allowed only when the release notes declare database compatibility. Otherwise:

1. Stop the application.
2. Pin the previous image tag.
3. Restore the database backup created immediately before the upgrade.
4. Start exactly one replica and verify health plus known data.

This full rollback loses data written after the upgrade. Without a matching backup, a downgrade is unsafe; keep the new version running, preserve the database, and investigate through Troubleshooting.