Rename runBleThroughputTest to runThroughputTest, and prepare the v0.4.0 release - #149
Merged
Merged
Conversation
Nothing about this measurement is BLE-specific. It asks the device to blast a dummy buffer (debug command 0x0B) and counts what arrives on the attached transport, so it measures a Web Serial link exactly as it measures a Web Bluetooth one - verisense-device-console has been running it over USB serial all along, under a button labelled "BLE Throughput Test". The name was the only thing claiming otherwise, and a caller who believed it would skip the test on a serial connection for no reason. BleThroughputTestOptions and BleThroughputTestResult are renamed to ThroughputTestOptions and ThroughputTestResult. The old names stay as a forwarding method and two type aliases, all @deprecated, so the consoles keep working on their current vendored builds. The doc comment now separates what genuinely is link-specific: PHY, connection interval, MTU and packets per connection interval over BLE; that link's own ceiling over serial. packetsReceived is documented as chunks - BLE notifications, or serial reads. typecheck, lint, build and the full vitest suite (1889 tests) pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.
Tip: disable this comment in your organization's Code Review settings.
The file had a single [Unreleased] section holding all 103 entries, back to 0.1.0 - so it could not answer "what changed in the version we are running", which is the one question a consumer's sdk-source.json stamp makes them ask. The entries are unchanged, all 103 of them, and none moved between Added / Changed / Fixed. What moved is which version heading they sit under, derived from git rather than judgement: each entry sits under the first package.json bump at or after the commit that introduced it, dated by that bump's commit. Merge ordering sent the version backwards more than once (0.1.23 -> 0.1.21 -> 0.1.22 -> 0.1.23 across two days), so a bump only counts when it exceeds every version before it; without that the ExG codec landed under 0.1.23 when its own release commit says 0.1.24. Seven of the thirteen sections are confirmed by their release commit's subject line - 0.1.22, 0.1.23, 0.1.24, 0.1.25, 0.1.26, 0.2.1 and 0.3.0 all name what this places under them. The 0.1.8-dock.N prereleases are folded into 0.1.8, the release that carried that work. The ten entries written since the 0.3.0 bump - the DEV-1021 and DEV-1023 work, and this branch's rename - become 0.4.0. A preamble note explains the gap the reconstruction exposed: v0.1.1 to v0.1.7 are the only tags and GitHub releases, while hand bumps for vendoring carried package.json to 0.3.0. Cut Release is the only thing that publishes and it tags every time, so those dozen versions were never published - they reached the consoles as vendored dist/ builds, which is how the consoles consume the SDK anyway. AGENTS.md now draws that distinction where the vendoring instruction sits, since following that instruction is what produced the drift, and asks for the changelog to be rolled in the pull request before a release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
marknolan
force-pushed
the
throughput_test_naming
branch
from
September 17, 2026 18:34
9cfe385 to
6842f69
Compare
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.
Two commits: the rename this PR was opened for, and the release prep that has to
land with it (the changelog roll conflicts with anything else that edits
[Unreleased], so it cannot sensibly be a second PR).1.
runBleThroughputTest()→runThroughputTest()Nothing about this measurement is BLE-specific. It asks the device to blast a
dummy buffer (debug command
0x0B) and counts what arrives on the attachedtransport, so it measures a Web Serial link exactly as it measures a Web
Bluetooth one —
verisense-device-consolehas been running it over USB serialall along, under a button labelled "BLE Throughput Test". The name was the only
thing claiming otherwise, and a caller who believed it would skip the test on a
serial connection for no reason.
BleThroughputTestOptions/BleThroughputTestResult→ThroughputTestOptions/ThroughputTestResult@deprecated, so both consoles keep working on the builds they have vendored.interval, MTU and packets per connection interval over BLE; that link's own
ceiling over serial.
packetsReceivedis documented as chunks — BLEnotifications, or serial reads — rather than notifications alone.
No behaviour change: the deprecated method forwards unchanged, and the renamed
types are the same shapes.
2. Release prep: the changelog, and what a release is
CHANGELOG.mdheld all 103 entries in one[Unreleased]section, back to0.1.0, so it could not answer "what changed in the version we are running" —
the one question a consumer's
sdk-source.jsonstamp makes you ask.The entries are unchanged and none moved between Added / Changed / Fixed.
What moved is the version heading each sits under, derived from git rather than
judgement: the first
package.jsonbump at or after the commit that introducedit, dated by that bump. Merge ordering sent the version backwards more than once
(
0.1.23 → 0.1.21 → 0.1.22 → 0.1.23across two days), so a bump only countswhen it exceeds every version before it — without that rule the ExG codec landed
under
0.1.23when its own release commit says0.1.24.Seven of the thirteen sections are confirmed by their release commit's subject
line:
0.1.22,0.1.23,0.1.24,0.1.25,0.1.26,0.2.1and0.3.0each name the work this places under them. The
0.1.8-dock.Nprereleases foldinto
0.1.8, the release that carried that work. The ten entries written sincethe
0.3.0bump (DEV-1021, DEV-1023 and this branch's rename) become0.4.0.The reconstruction exposed a gap worth stating, so the preamble states it:
v0.1.1–v0.1.7are the only tags and GitHub releases, while hand bumps forvendoring carried
package.jsonto0.3.0. Cut Release is the only thing thatpublishes and it tags every time, so that dozen of versions was never published
— they reached the consoles as vendored
dist/builds, which is how theconsoles consume this SDK anyway.
AGENTS.mdnow draws that distinction right where the vendoring instructionsits, since following that instruction is what produced the drift.
## [0.4.0] - 2026-09-17is dated for the release intended immediately afterthis merges (Cut Release → minor).
Verification
npm run typecheck,npm run lint,npm run buildandnpm test(1889 tests,96 files) pass locally, and CI is green. The changelog restructure was checked
mechanically: all 103 entry blocks appear verbatim in the rewritten file, and
the file is prettier-clean.
Companion PRs
🤖 Generated with Claude Code