Metric 0.1.7

This release makes migrations from Sentry less disruptive and makes personal API tokens fine-grained enough for build-tool and CI workflows.

What's new

• Keep existing Sentry DSNs during migration. Metric can map an existing Sentry public key and external project ID to a Metric project, so deployed clients do not need a DSN configuration change. The existing public hostname, port, TLS endpoint and any path prefix still need to route to Metric. Imported mappings use dedicated Metric keys and keep the normal project policy, rate limits and revocation behavior. See Move from Sentry without changing client DSNs.
• Fine-grained personal API tokens. Keep the existing presets or use Custom / Advanced to select individual scopes. The UI only exposes scopes that the creating user currently holds, and organization owner/delete permissions are intentionally not exposed as personal-token checkboxes.
• Sentry CLI and build-tool uploads. The new Sentry CLI uploads preset grants debug_file:read, debug_file:write, artifact:read, and artifact:write. This fixes source-bundle and artifact-bundle upload flows that previously returned 403 because the token UI could not grant artifact:write. Thanks for #6!
• Schema generation 21. Existing generation-20 installations migrate automatically to generation 21, which adds the DSN mapping collection. A complete generation-19 installation runs the registered 19 → 20 → 21 migration chain.

Updating from 0.1.6

Back up the Metric database, BlobStore and installation secrets together before updating. Keep the existing secrets and follow the update guide.

Metric 0.1.6 uses schema generation 20. On first startup, 0.1.7 automatically migrates a complete generation-20 database to generation 21. A generation-19 database runs both registered transitions. Databases older than generation 19 are not supported by this migration chain; do not erase them or edit their schema marker.

During migration, normal API/SDK requests receive HTTP 503 and /ready stays unavailable; /live remains healthy. Behind Kubernetes Ingress, use logs or a direct pod port-forward to see progress while the pod is not ready.

Migrations are forward-only. Switching the image back to 0.1.6 does not undo the database migration. Returning to that version requires restoring the pre-upgrade database and matching blob backup, with the original secrets.