Stalwart 0.16.20 on the live instance #134

Closed
opened 2026-08-31 03:59:11 +00:00 by jcoffey-dev · 0 comments
Owner

INBUXA moved 0.16.19 → 0.16.20 on 2026-08-31 with eight seconds of downtime. A 0.16.x → 0.16.x upgrade is a binary replacement — no data migration, no config change. The store was cold-copied first; the old binary is kept in place for rollback.

Docs only. No code changes, because none were needed.

Why nothing broke

I read the full 0.16.19...0.16.20 diff against what ihasmail actually calls:

  • Session capabilities, blob, quota, submission, Sieve and the registry objects behind self-service credentials are untouched. Verified live after the upgrade: all 17 session capabilities present, and urn:stalwart:jmap still absent at session level — so the three-place lookup that sign-in turns on remains both correct and necessary.
  • The Locale enum moved from POSIX names to BCP-47 (en_USen-US, POSIX dropped, aa_ER@saahossy-ER). normalizeLocale in server/src/upstream.ts already strips @modifier, replaces _ and rejects POSIX, so BCP-47 passes straight through. Part of that function is now dead code rather than broken.
  • Default calendar/address book resolution now falls back to the lowest document id instead of only resolving when exactly one exists. InviteCard already had the fallback; this only makes it deterministic.
  • Email/set create now injects a Message-ID when absent. Free threading improvement for mail composed in ihasmail — replies to it can now reference it.
  • Conference links in invite emails, and 24 more invite-email translations, are server-side only. They do not touch ihasmail's own strings.

What changed here

README — the badge, 0.16.19 → 0.16.20. The stalwart-migrator line keeps saying 0.15.5 → 0.16.19, because that is the run it describes.

KNOWN-ISSUES — three edits:

  1. The header records the upgrade, and says plainly that the entries' dates stay at 0.16.19 because that is what was actually run. The upgrade was read from the diff, not re-run. This file has been wrong before by recording something as verified live when it had never run, so it seemed worth being explicit rather than silently promoting every date.
  2. The one-line recurrence entry is rewritten. It said per-occurrence overrides "aren't supported by the server yet" — 0.16.20 supports them, so the entry now says what the server does, what ihasmail still does instead, and points at #132.
  3. The RFC 8984 entry said CalendarEvent/set refuses a synthetic id. It no longer does. Reworded to the past tense, keeping why RSVP resolves baseEventId — which is still the right behaviour, just no longer the only option.

Follow-ups

  • #132 — per-occurrence edit and delete, including the silent-drop trap in the server's per-occurrence patch validator.
  • #133 — move the base-id resolution into the store. 0.16.20 removed the error that used to catch a synthetic id reaching destroy; it now deletes one occurrence and reports success.

Merged 2026-08-30 as coffey-labs/ihasmail@12157f47bf

Rebuilt from: git history, session transcript.

INBUXA moved **0.16.19 → 0.16.20** on 2026-08-31 with eight seconds of downtime. A 0.16.x → 0.16.x upgrade is a binary replacement — no data migration, no config change. The store was cold-copied first; the old binary is kept in place for rollback. Docs only. No code changes, because none were needed. ## Why nothing broke I read the full [0.16.19...0.16.20 diff](https://github.com/stalwartlabs/stalwart/compare/v0.16.19...v0.16.20) against what ihasmail actually calls: - **Session capabilities, blob, quota, submission, Sieve and the registry objects behind self-service credentials are untouched.** Verified live after the upgrade: all 17 session capabilities present, and `urn:stalwart:jmap` still absent at session level — so the three-place lookup that sign-in turns on remains both correct and necessary. - **The `Locale` enum moved from POSIX names to BCP-47** (`en_US` → `en-US`, `POSIX` dropped, `aa_ER@saaho` → `ssy-ER`). `normalizeLocale` in `server/src/upstream.ts` already strips `@modifier`, replaces `_` and rejects `POSIX`, so BCP-47 passes straight through. Part of that function is now dead code rather than broken. - **Default calendar/address book resolution** now falls back to the lowest document id instead of only resolving when exactly one exists. `InviteCard` already had the fallback; this only makes it deterministic. - **`Email/set` create now injects a `Message-ID`** when absent. Free threading improvement for mail composed in ihasmail — replies to it can now reference it. - Conference links in invite emails, and 24 more invite-email translations, are server-side only. They do not touch ihasmail's own strings. ## What changed here **README** — the badge, 0.16.19 → 0.16.20. The stalwart-migrator line keeps saying 0.15.5 → 0.16.19, because that is the run it describes. **KNOWN-ISSUES** — three edits: 1. The header records the upgrade, and says plainly that the entries' dates stay at 0.16.19 because that is what was actually run. The upgrade was read from the diff, not re-run. This file has been wrong before by recording something as verified live when it had never run, so it seemed worth being explicit rather than silently promoting every date. 2. The one-line recurrence entry is rewritten. It said per-occurrence overrides "aren't supported by the server yet" — 0.16.20 supports them, so the entry now says what the server does, what ihasmail still does instead, and points at #132. 3. The RFC 8984 entry said `CalendarEvent/set` *refuses* a synthetic id. It no longer does. Reworded to the past tense, keeping why RSVP resolves `baseEventId` — which is still the right behaviour, just no longer the only option. ## Follow-ups - #132 — per-occurrence edit and delete, including the silent-drop trap in the server's per-occurrence patch validator. - #133 — move the base-id resolution into the store. 0.16.20 removed the error that used to catch a synthetic id reaching `destroy`; it now deletes one occurrence and reports success. **Merged** 2026-08-30 as coffey-labs/ihasmail@12157f47bf96 <sub>Rebuilt from: git history, session transcript.</sub>
This repo is archived. You cannot comment on issues.