# v0.10.1 — A release that says which release it is

**2026-08-14**

## TL;DR

The server reported itself as `v0.7.0` in its startup banner, its health endpoint
and its MCP handshake — through v0.8.0, v0.9.0 and v0.10.0. And the production compose
file carried *two* `${MCP_VERSION:-...}` defaults, one naming the image and one telling
`npm install -g` which release to bake in. Bumping only the first produced an image
labelled `firefox-docker-mcp:0.10.0` containing the 0.9.0 package: a deploy that
reported success, passed a smoke test, and shipped nothing.

Both are now written by the release script, so neither can drift again.

## Why this is not cosmetic

A version string is the first thing anyone checks when a deploy looks stale. A *wrong*
one is worse than none, because it is trusted. Here it did real damage twice over: the
stale `0.7.0` banner made a correctly-built container look broken, and the split compose
default made a broken container look correct. The v0.10.0 deploy was reported as live
when the running server did not contain a single line of it — caught only because the
banner was wrong in the other direction and someone read the logs.

The pattern worth naming: **a version that nothing reads back will drift, and the moment
it matters is the moment you cannot trust it.**

## What changed

| | |
|---|---|
| **`SERVER_VERSION` is generated** | `src/config/constants.ts` is rewritten by `scripts/sync-release-version.mjs` on the `npm version` hook, next to the bridge package bump it already did. Marked do-not-edit. |
| **Both compose defaults move together** | The script rewrites every `${MCP_VERSION:-...}` in `docker/docker-compose.yaml`, and reports how many it found, so a third one added later is covered without anyone remembering. |
| **Fails loudly** | A missing `SERVER_VERSION` line or zero compose defaults aborts `npm version` before it commits or tags, the same way a missing release note already did. |

No behaviour change to any tool. v0.10.0's tab scoping is unaffected — it was correct in
the published package all along; only the container was built from the wrong one.

## Upgrading

Rebuild the production image. The build argument now defaults to the current release, so
`cd docker && docker compose build mcp && docker compose up -d --no-deps mcp` bakes in
what the tag says. Confirm with `docker exec firefox-mcp npm ls -g --depth=0`, which
reports the package version rather than the image label — the two disagreeing is exactly
the failure this release removes.