v3.10.0 was tagged and then withdrawn. **Nothing was ever available
under that number**: no container image and no release asset was ever
published, so no user could have pulled it.
This renames the notes and the CHANGELOG section. No product code
changes.
## Why it had to be renumbered
Three things, in the order they bit.
**1. The image never built.** `release-fast-path.yml` re-tags `:edge` to
`:vX.Y.Z` when the `:edge` revision label matches the tagged commit, and
dispatches `deploy.yml` when it does not. The tagged commit was
documentation-only, so the `paths-ignore` from #1949 meant no `:edge`
existed for it and the fallback ran. That part behaved correctly. The
fallback then published nothing, because every GHCR step was gated on
`github.event_name == 'push'` and a dispatch is not a push. It built
locally, reported `success`, and pushed nothing.
Fixed in #1951, but that fix is not in the `v3.10.0` tag, and a
`workflow_dispatch` runs the workflow file **from the ref it targets**.
So the existing tag could not be made to publish.
**2. The assets never uploaded.** I created the GitHub release by hand
before the workflow reached it, and `action-gh-release` cannot update an
immutable release. The correct procedure is to push the tag and let the
workflow create the release.
**3. The tag name cannot be reused.** GitHub's immutable releases keep a
tag name reserved even after the release is deleted:
```
remote: - Cannot create ref due to creations being restricted.
```
I established that only after deleting the release, which is the wrong
order. The lesson, written into the commit message so it survives: check
whether a tag can be rewritten before removing anything that depends on
it.
## What is in v3.10.1
The same 111 commits, plus the three CI fixes that landed after the
v3.10.0 tag (#1949, #1950, #1951). Those are listed in their own section
in the notes. **No product code differs** from what was tagged as
v3.10.0.
All 69 SHA references in the notes were re-verified after the rename.
## Procedure for this tag
Push the tag and stop. The workflow creates the release and attaches the
assets. Do not create it by hand.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Release notes for the first tag since `v3.9.2` on 2026-06-13. **111
commits**, and no auto-generated coverage bumps fall in this range, so
all 111 are substantive.
Nothing here changes behaviour. It is `docs/release-notes/v3.10.0.md`
plus a `CHANGELOG.md` section.
## Verification
The header promises that every bullet ends with a SHA you can `git
show`. That is checked mechanically rather than trusted: all **69**
references were confirmed to point at a commit that exists and whose
subject line contains the issue or PR number cited beside it. Zero
mismatches.
## Two things operators need, and both are silent failures
The urgency line leads with the first one on purpose.
1. **CARTO requires an API key** on its raster basemaps since 2026-08.
Without one every tile is served watermarked with HTTP 200. Nothing
errors, no healthcheck fires, and the only way to notice is to look at a
tile. Anyone upgrading needs to set `map.tiles.providers.carto.key`.
2. **`pathTrust.minHashBytesForMapping` ships at 1**, which is the
existing behaviour, so an upgrade changes nothing on its own. The note
states what raising it to 2 would actually cost, with numbers from a
live instance (56% of path-hop observations are 1-byte, 41% of repeaters
use a 1-byte hash), because there is no UI to undo it.
The relay `last_seen` fix is quantified the same way rather than
described as "improved": for repeaters that relayed within the last
hour, the gap between `last_relayed` and `last_seen` drops from a median
of 12,062 s to 193 s, and the share more than five minutes behind falls
from 96% to 39%.
## A theme worth naming
Three of the highlights are the same defect in three places: something
is operable before its own setup has finished. The Live view toggles are
inert for about 100 ms after paint, the colour picker's deferred focus
undid arrow-key navigation so Enter assigned the wrong colour, and an
analytics theme-refresh discarded the filter you had just applied. All
three were first written off as flaky tests, twice by me. Each is now
fixed with a regression test that fails on the previous commit.
## Sequencing
This should land, and the `v3.10.0` tag be cut, **before** the Go 1.27
upgrade in #1946. A toolchain bump changes the compiler, the runtime and
`gofmt` for everything at once; landing it on top of 111 unpublished
commits means a later regression cannot be separated from the toolchain.
#1946 itself says no 1.27-only features are being adopted, so there is
no cost to waiting one release. A tag first also gives a known-good
bisect point.
## Not done
The CHANGELOG has no `3.9.2` section and did not have one before this
change. I left that gap alone rather than reconstructing it
retroactively.
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Release notes for v3.8.4 — the "Phosphor migration" release. Six PRs
(#1649–#1654, tracking #1648) plus three followup fixes
(#1659/#1660/#1665) replaced all decorative emoji in the UI with
Phosphor sprites and added a lint gate to prevent regression.
## Verification summary
Test plan: `workspace-meshcore/test-plans/v3.8.4-cdp-test-plan.md` (93
tests, 16 sections).
- Initial run (pre-#1665): 56 pass / 22 partial / 5 fail / 14 skipped.
Two BLOCKER lint-gate breaches in observers and analytics Channels.
- Final run (post-#1665, hot-patched to staging): both blockers ✅ —
v384-1.2 (11 chips, 11 sprites, 0 emoji), v384-12.18 (315 lock sprites,
0 🔒 emoji).
- 22 partials are plan selector drift, not code regressions; deferred to
v3.8.5.
## Tagging
Per the notes file, this is ready for `git tag -a v3.8.4 037dc8c4 -m
"v3.8.4"` after merge — **not executed by this PR**.
## Review
Draft for user review. Will be marked ready / merged before tag.
---------
Co-authored-by: meshcore-bot <bot@meshcore.dev>
- Release notes for 95 commits since v3.4.1
- OpenAPI/Swagger docs: /api/spec and /api/docs called out everywhere
- Deployment guide: new API Documentation section
- README: API docs link added
- FAQ: 'Where is the API documentation?' entry
- Test plans for v3.4.2 validation
