From a0c789b3ba83a31d4f264341f7ee3486c5776bc7 Mon Sep 17 00:00:00 2001 From: Bryan Van Deusen Date: Sat, 29 Aug 2026 00:27:43 -0400 Subject: [PATCH] docs: the image tag list said something step 6 stopped being true MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `:` is on `main` only now — a sha tag per dev push was a rollback target nobody had ever pulled — and `:` never existed as an image tag after rule 145 was narrowed. Both were still documented. `docs/android-distribution.md` also said `:dev`, `:latest` and `:` all ship a client, which is now two-thirds true and misses the more useful fact: the channel IS the image you run, so a stable server serves a stable client. Worth saying because until step 3 it was hard-wired to the dev release on every branch and did the opposite. This push is also the skip-if-exists verification. It touches neither client's file set, so both `decide` jobs should report the channel already serving the current version and skip a 6- and a 9-minute build — while the guard still runs on that path (§6.3). #3146 Co-Authored-By: Claude Opus 5 --- README.md | 6 ++++-- docs/android-distribution.md | 18 ++++++++++++------ 2 files changed, 16 insertions(+), 8 deletions(-) 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.