docs: release notes for v3.10.0 - #1948
Merged
Merged
Conversation
111 commits since v3.9.2 (2026-06-13). No auto-generated coverage bumps fall in this range, so all 111 are substantive; the previous release note's split between substantive and coverage commits does not apply here. Every one of the 69 SHA references was checked mechanically: the commit exists and its subject line contains the issue or PR number cited next to it. That is the promise the header makes, so it is verified rather than assumed. Flagged for operators, because two of these are silent: - CARTO now requires a key on its raster basemaps. Without one every tile is served watermarked with HTTP 200, so no error surfaces and no healthcheck fires. This one needs action on upgrade. - pathTrust.minHashBytesForMapping ships at 1, which is the existing behaviour. The note states what raising it to 2 would actually cost, measured on a live instance, since there is no UI to undo it. Also moves the pending /api/paths/inspect entry out of [Unreleased] into the 3.10.0 section. Not done: the CHANGELOG has no 3.9.2 section and did not have one before this change. I did not invent one retroactively. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PQS3XLoPD98yu9pxdRujqg
115 pull requests from 13 people, counted by PR and restricted to what merged after v3.9.2 was tagged. The per-person totals sum to 115. Six PRs were rebased onto master by someone other than their author, because the branches had gone stale while the queue was stalled. I described those at the time as "rebased with authorship preserved", and that was only half true: authorship is preserved on the branch, but this repository squash-merges, and a squash takes the PR author as the commit author. Checked rather than assumed: git log --format=%an on all six merge commits returns the rebaser, not the author. So the list is a correction of the record, not a courtesy. The third column names the pull request each piece of work actually came from. It matters most for nullrouten0, who has zero merged PRs under their own name in this release and wrote the CARTO basemap fix the release leads with. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PQS3XLoPD98yu9pxdRujqg
efiten
added a commit
that referenced
this pull request
Sep 3, 2026
Two documentation-only PRs were running the full pipeline simultaneously this afternoon: #1948 (`CHANGELOG.md` plus a release note) and #1947 (deleting a stale `docs/DEPLOYMENT.md`). Each spends about 12 minutes on Go Build & Test and about 16 minutes on Playwright to establish that a text file does not break a browser. **The cost is the queue, not the minutes.** On the same afternoon a `pull_request` run was created at 12:13 and its first job did not start until 16:19. Four hours in the queue. Every unnecessary run pushes the ones that matter further back, and this repository has been merging heavily today. ## Checked before adding the filter Rather than assumed: - **Nothing reads markdown at build or test time.** Grepping every Go and JS source for a runtime read (`ReadFile`, `readFileSync`, `os.Open`) of a `.md` path returns nothing. The `docs/` matches in `cmd/` and `test-*.js` are all comments pointing at documentation. - `/api/docs` serves Swagger UI generated from `cmd/server/openapi.go`, not from `docs/`. - `docs/` holds markdown plus screenshots (`png`, `gif`) and no build input. - **This workflow has no tag trigger**, so release tagging is unaffected; that runs from `release-fast-path.yml`. Worth stating explicitly given a `v3.10.0` tag is imminent. `paths-ignore` skips only when **every** changed file matches, so a PR touching both code and documentation still runs the full pipeline. ## The trap, stated in the file If required status checks are ever enabled on master, a skipped workflow never reports, and a docs-only PR would wait forever on a check that cannot arrive. At that point this needs to become a change-detection job with conditional heavy jobs rather than a trigger filter. Master has no required checks today. Verified: the branch protection endpoint returns 404. That caveat is in a comment above the `on:` block, not just in this description, because the person who enables required checks in six months will be reading the workflow and not this PR. ## Note This PR itself changes only `.github/workflows/deploy.yml`, so it is not documentation-only and will run the full pipeline, as it should. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
efiten
added a commit
that referenced
this pull request
Sep 3, 2026
Follow-up to #1949, correcting a pattern I did not check before proposing it. #1949 used `'**/*.md'`. That reads as requiring a directory component, so it covers `docs/release-notes/v3.10.0.md` but not `CHANGELOG.md` or `README.md` at the repository root. Since `paths-ignore` skips only when **every** changed file matches, one uncovered root file is enough to run the whole pipeline anyway. GitHub's own example for "any file with this extension" is `'**.js'`, with no slash. `'**/*.md'` does not appear in their documentation at all. `'**.md'` covers root and subdirectories both. ## What this does not establish #1948 (`CHANGELOG.md` plus a release note) did start a full run after #1949 landed, and that is what prompted this. But there is a second candidate explanation I did not rule out: that PR's branch predates #1949, so its workflow file may simply not have carried the filter yet. I am not claiming to have proven which one it was. The fix is correct either way, and shipping the documented pattern is better than defending the first cause I noticed. The real test is the next docs-only PR opened from a branch that already contains the filter. The reasoning is in a comment above the `on:` block, not only in this description. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release notes for the first tag since
v3.9.2on 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.mdplus aCHANGELOG.mdsection.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.
map.tiles.providers.carto.key.pathTrust.minHashBytesForMappingships 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_seenfix is quantified the same way rather than described as "improved": for repeaters that relayed within the last hour, the gap betweenlast_relayedandlast_seendrops 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.0tag be cut, before the Go 1.27 upgrade in #1946. A toolchain bump changes the compiler, the runtime andgofmtfor 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.2section and did not have one before this change. I left that gap alone rather than reconstructing it retroactively.