Repository navigation
release: v0.3.2 (patch) — analytics fixes, staging gate, upstream docs #202
Description
Filed after the fact. v0.3.1 got #182 opened before the tag with the pre-flight record on it. v0.3.2 got a Citadel task and nothing on GitHub, so until now the release running on prod had no record anyone but the session could read. That is a miss on ISSUE FIRST for the most side-effectful action of the night.
Tag v0.3.2 (annotated, bb023275) at commit 030be432, pushed 2026-10-12 03:0x UTC.
Contents
Five commits since v0.3.1, nine files, no migrations and no schema change [verified: git diff --name-only v0.3.1..030be432].
| commit | |
|---|---|
030be432 |
#192 Analytics → Channels showed hashes in decimal instead of hex (Jeymz, fixes #190) |
448745c9 |
#194 staging healthcheck gate polled Docker health for 90s against a longer cold start (ITblacksheep, fixes #195) |
26019e36 |
#191 Relay Airtime Share assumed SF 8 and showed a frequency with no effect on ToA (Jeymz, fixes #189) |
aa40e9e3 |
#163 docs/UPSTREAM.md gaps found by adversarial review |
4a6d1eb4 |
#163 docs/UPSTREAM.md initial |
Behaviour change on prod, deliberate
#191 moves the default LoRa preset from SF 8 → SF 7 and drops freq from the defaults [repo: cmd/server/relay_airtime_share.go defaultLoRaPreset].
Prod sets no analytics.loraPreset block [verified: prod config.json → ABSENT], so prod runs on those defaults. Relay Airtime Share numbers on prod changed with this release and are now correct. The owner confirmed OKI-Mesh runs US defaults, which is SF 7, so no explicit config block is needed.
freq remains in the struct as json:"freq,omitempty" [repo: cmd/server/config.go:1035], so no deployed config fails to parse.
Pre-flight, verified before tagging
- dev was running
030be432— the exact commit tagged[verified: dev /api/stats] - that commit's master run
38196112478concluded success, including the dev deploy[verified: gh api .../jobs] - no migrations, so no database backup needed (unlike v0.3.0, which did)
- tag did not already exist on the remote
Deploy result, verified on the box
Fast path: :edge re-tagged to :v0.3.2, no rebuild. Both jobs of run 38199558490 succeeded, prod cleared its 300s healthcheck without triggering auto-rollback.
[box: /api/stats + docker on deadbeef, 2026-10-12]
version |
v0.3.2 |
commit |
030be43 |
| container | Up 5 minutes (healthy), RestartCount=0 |
| in-container crashes | 0 (exited: corescope- over 300 log lines) |
| ingesting | 9,188 packets/hour, 1,629 nodes |
| health thresholds | 56h / 104h — the #183 config change survived the deploy |
Prod and dev are on the same commit; nothing unreleased on master.
Noted at the time, not hit
Prod's healthcheck window is 300s and prod's measured cold start earlier the same night was ~260s, roughly 40s of margin. It cleared. The thinness of that margin is why #196 exists — nothing records time-to-ready, so the margin is only ever visible when someone measures it by hand.
Context
First release through the new tag ruleset 24905428 (v* restricted to admins). The push printed Cannot create ref due to creations being restricted and succeeded only via admin bypass, confirming the restriction is live and would have stopped a write collaborator.
The production GitHub Environment exists but is deliberately not wired to deploy-prod.yml, so this release followed the same path as v0.3.1 with no approval gate. See #197.
Closing as done — this exists for the record, not as open work.
Activity
diffwireauto commentedon Oct 12, 2026
Closing on creation. This records a release that already shipped and was verified on prod; it is not open work.
Filed late. v0.3.1 got #182 opened before its tag with the pre-flight record on it; v0.3.2 got a Citadel task and nothing on GitHub, so the release currently running on prod had no record readable by anyone but the session that cut it. Caught when the owner asked whether everything we worked on had an issue.