liminis-context-graph v0.15.0 — lbug 0.20.3, and a one-way storage migration

[verveguy]

v0.15.0 moves the graph engine from lbug 0.18.1 to 0.20.3. It carries a one-way storage migration (42 → 47) — read Upgrading before you take it. There are no API changes, and no change to the platform matrix: Windows, macOS and Linux all remain supported.

Upgrading

1. The database migrates one way. A database at storage version 42 — which is everything 0.14.x shipped — opens directly under the new binary. No export, no reimport, WAL untouched. The first checkpoint rewrites it to storage 47, after which an older binary will not open it.

   To roll back: stop the service, move .lcg/db/ aside, and start the old binary. It rebuilds from the WAL.

2. Nothing else. No API changes, no configuration changes, no manual step.

What the upgrade brings

lbug 0.20.3 picks up fixes that the 0.18.1 rollback deliberately deferred, several on paths this project exercises continuously:

• ladybug#845 — heap corruption in the FTS query path when scans race committing writers. This service creates an FTS index and queries it concurrently as a live process.
• ladybug#883 — a SIGSEGV in the cached-prepared-statement path, reachable after enough parameterized queries in one session. Fixed outright in 0.20.3 rather than mitigated.
• ladybug#837 and #864 — primary-key-lookup row alignment, and silent row loss when LOAD FROM/UNWIND feeds a MATCH primary-key predicate.
• #894 and #884 — planner fixes and an ArrowResultCollector downcast fix.

It also forward-fixes a stale-row bug on the cached-plan fast path (ladybug#877/#878) affecting re-executed parameterized queries — the normal calling pattern for this engine, though 0.18.1 does not appear to exhibit it.

Why 0.20.3, and not 0.20.4

The newest lbug patch is 0.20.4. This release pins 0.20.3 deliberately, because lbug 0.20.4 crashes on Windows inside the published vector and fts extensions.

Upstream publishes extension binaries per minor version, and the files served under v0.20.0 are 0.20.2-era builds. They are ABI-compatible with a 0.20.2 or 0.20.3 core, and not with 0.20.4's: on 0.20.4 index creation faults the process — full-text every time, vector intermittently. On 0.20.3 the same bytes ran 110 vector and 25 full-text cycles clean, under both OpenSSL DLL vendors.

Reported upstream as LadybugDB/ladybug#971, which the maintainer has acknowledged as an extension ABI break; the fix is expected in 0.21.x. Linux and macOS are unaffected by the choice — 0.20.3 carries the same storage version and the same fixes either way.

What was verified

Every published artifact was downloaded, checksum-verified, and exercised — not a local build:

• All four targets: the shipped binary opened a real storage-42 database and the migration was confirmed on disk, by reading the database header go from 42 to 47. Not inferred from queries still working.
• Windows 11 x64: the semantic end-to-end suite ×10 from the published zip, with no OpenSSL DLL reachable on PATH and no LCG_LBUG_HOME set, so the bundled extensions resolved exactly as they will for a user. Migration, reopen and WAL rebuild all clean. Zero crash-reporting events.
• macOS: recompute-vs-stored agreement at min_cosine 1.000000 across 4,126 vectors, so the engine change does not perturb embedding recompute exactness.
• Linux (x86_64 and aarch64): full CI, plus published-artifact migration checks.

The same Windows non-claims as 0.14.3 still stand: no test on a machine lacking the Visual C++ runtime, no run of the PowerShell installer end to end, x64 only, and no endurance or Unicode/long-path coverage.

Full detail: docs/releases/0.15.0.md · CHANGELOG