From 8e01ecdde2c09a656f40f0669149822c73e9ca0c Mon Sep 17 00:00:00 2001 From: Luxit Date: Mon, 12 Oct 2026 16:35:57 +0200 Subject: [PATCH] Sync the self-hosting stack --- CHANGELOG.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 947b878..1a9bfd3 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,6 +9,31 @@ one of them changed. An entry says which artefact and which version, so `web 0.1 Every version published to a channel appears here. Nothing is written from memory afterwards: a build cannot be published without its entry. +## 2026-10-12 — Ready for the release that removes the old access columns `api 0.140.0` + +**Nothing changes on your screens.** This build is the step before the release that removes the +columns the old access model left behind — the role word on each membership, the shell and screen +switches on a grant, and the credential grant table. It stops reading and writing them entirely, so +that the release removing them can roll out on a cluster without errors from the pods it replaces, +which would otherwise still ask for them while it rolls. + +**It cannot upgrade an instance that never ran `api 0.138.0` or later.** The translation of roles, +grants and credential rows into profiles is no longer in this build. If your instance comes from +before `api 0.138.0`, the migration stops **before changing anything** and says so: install +`api 0.139.1` first — it translates, says what it moved, and moves nothing twice — then this one. On +Kubernetes the migrate Job goes red and the previous version keeps serving; on compose the API stays +down until then, deliberately, because starting would leave every member, owners included, with no +rights at all. An instance that has run `api 0.138.0` or later, and a fresh install, go through +without noticing. + +**A seeded demo owner gets the assistant's access on the first boot**, rather than on the next one — +or never, on a database that only ran the seed. + +Update the API image. No web or agent update is required, and nothing in the schema changes. The +release that removes the old columns comes next and will ask for `SCHEMA_ACCEPT_DATA_LOSS=true` for +that one run. Install this one everywhere first: on a cluster, the removal must not roll out over +pods older than this. + ## 2026-10-12 — An organization keeps its owner `api 0.139.1` **Deleting an account could leave an organization without an owner.** The Admin Center refuses to