diff --git a/README.md b/README.md index b8f4489..60b5bcb 100644 --- a/README.md +++ b/README.md @@ -99,8 +99,10 @@ Then open `http://:5000` and register — **the first account becomes the unset, a signing key is generated and persisted in the database (sessions survive restarts). - Uploaded images live under the `thoughtsync-data` volume at `/var/thoughtsync`. - The app waits for the database and runs migrations (`alembic upgrade head`) automatically on start. -- **Image tags:** `:latest` (stable, built from `main`) · `:dev` (latest `dev` build) · - `:` (immutable, for pinning / rollback). +- **Image tags:** `:latest` (stable, built from `main`) · `:dev` (latest `dev` + build) · `:` on `main` only (immutable, the rollback unit). There are + no version-shaped tags: nothing pins one, and the build reports its own version + at `/api/config` and `/health`. - **Putting it on the public internet:** there are four things to do first — close registration, terminate TLS and forward `X-Forwarded-Proto`, stop publishing the app port, and back up the attachment volume as well as the database. See diff --git a/docs/android-distribution.md b/docs/android-distribution.md index e69d836..506ea96 100644 --- a/docs/android-distribution.md +++ b/docs/android-distribution.md @@ -15,13 +15,19 @@ cannot talk to. **Normally: nowhere. It is already in the image.** -CI fetches the newest published Android build into every server image it builds, -so `:dev`, `:latest` and `:` all ship a client. `docker compose pull && -docker compose up -d` delivers a new server and a new client together, and there -is nothing to copy. +CI fetches the published Android build into every server image it builds, so +`:dev` and `:latest` both ship a client. `docker compose pull && docker compose +up -d` delivers a new server and a new client together, and there is nothing to +copy. -A versioned image therefore carries the *newest* client rather than one pinned to -that version. That is deliberate: the two negotiate a sync protocol version +**The channel is a property of the image you run.** A `:dev` image bakes in the +dev-channel APK, `:latest` the stable one — so pointing a phone at a stable +server gets it a stable client, with no second place holding that decision. (Until +M314 step 3 the fetch was hard-wired to the dev release on every branch, so a +stable server served a dev client.) + +An image therefore carries the *newest* client on its channel rather than one +pinned to a version. That is deliberate: the two negotiate a sync protocol version before they link, so a mismatch is caught by the handshake rather than by pinning.