Tracker release and revocation

Release a new version

1. Set version in packages/tracker/package.json to the new version. The release script refuses anything else.
2. Build and record the release:
   pnpm --filter tracker release <x.y.z>
   
   Expected: gzip size <old> -> <new> (<n>%) and the new manifest entry as JSON. The script refuses a version that exists or is not newer than the newest, and never overwrites a file.
3. Check the release directory, a byte-identical rebuild and the size budget:
   pnpm --filter tracker verify-releases
   
   Expected last line: releases verified against HEAD. CI runs the same against the change’s base and fails if any committed release file or entry changed.
4. Run the tracker’s tests and the browser suites that pin a version: pnpm --filter tracker test, then make gateway-it and make webpath (see the Makefile for their prerequisites).
5. Commit, merge, and tag tracker-v<x.y.z>. release-tracker.yml checks that the tag names the newest committed release and publishes it (attestation and npm publication wait for the GitHub Actions account issue and input I9; ../security/verify-tracker.md sections 3 and 6).
6. Ship the files: the gateway and control plane images copy packages/tracker/releases, so tag a platform release and roll it out (make <env>-deploy ROLLING=1 ...). Until then the new version answers 404 at the edge.
7. Tell tenants: the console offers the newest non-revoked version; existing snippets keep the version they pinned. Tenants upgrade on purpose.

Revoke a version

1. Add the version with a reason to packages/tracker/releases/revoked.json:
   {
     "revoked": [
       {"version": "<x.y.z>", "reason": "<one line, shown in logs and to operators>"}
     ]
   }
   
   Leave releases/<version>/ and its manifest entry in place: removing them would break the immutability check and the record of what was served.
2. pnpm --filter tracker verify-releases, then commit and tag a platform release, and roll it out to every edge and core node. Pages that load the version get 410 and record nothing; snippet requests for it get 410 tracker_version_revoked. A page that still runs the file from its cache or a self-hosted copy keeps sending: from 1.2.0 those events name the release and the gateway refuses them with 410 (rejected_revoked_version on the site’s counters); events of 1.0.0 and 1.1.0 carry no release name and still pass.
3. On a node that already runs an image with the new list, a reload without restart is possible: SIGHUP makes the gateway read revoked.json (and the DB-IP file) again, and the control plane reads the file on every snippet request. Inside an image the file only changes with a new image, so in practice step 2 is the path.
4. Tell the affected tenants which version to move to and why. Make sure a non-revoked version exists first: if every version is revoked, the console answers every tracker version is revoked.

Exercised