Skip to content

Rename runBleThroughputTest to runThroughputTest, and prepare the v0.4.0 release - #149

Merged
marknolan merged 2 commits into
mainfrom
throughput_test_naming
Sep 17, 2026
Merged

marknolan merged 2 commits into
mainfrom
throughput_test_naming

Conversation

@marknolan

@marknolan marknolan commented Sep 17, 2026 •

Copy link
Copy Markdown
Member

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 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 / BleThroughputTestResult → ThroughputTestOptions / ThroughputTestResult
  • The old names stay as a forwarding method and two type aliases, all
    @deprecated, so both consoles keep working on the builds they have vendored.
  • 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 — 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.md held all 103 entries in one [Unreleased] section, back to
0.1.0, so it could not answer "what changed in the version we are running" —
the one question a consumer's sdk-source.json stamp 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.json bump at or after the commit that introduced
it, dated by that bump. 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 rule 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
each name the work this places under them. The 0.1.8-dock.N prereleases fold
into 0.1.8, the release that carried that work. The ten entries written since
the 0.3.0 bump (DEV-1021, DEV-1023 and this branch's rename) become 0.4.0.

The reconstruction exposed a gap worth stating, so the preamble states it:
v0.1.1–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 that dozen of versions was never published
— they reached the consoles as vendored dist/ builds, which is how the
consoles consume this SDK anyway.

AGENTS.md now draws that distinction right where the vendoring instruction
sits, since following that instruction is what produced the drift.

## [0.4.0] - 2026-09-17 is dated for the release intended immediately after
this merges (Cut Release → minor).

Verification

npm run typecheck, npm run lint, npm run build and npm 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

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>

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@marknolan marknolan changed the title Rename runBleThroughputTest to runThroughputTest Rename runBleThroughputTest to runThroughputTest, and prepare the v0.4.0 release Sep 17, 2026
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
marknolan force-pushed the throughput_test_naming branch from 9cfe385 to 6842f69 Compare September 17, 2026 18:34
@marknolan
marknolan merged commit e3571c5 into main Sep 17, 2026
2 checks passed
@marknolan
marknolan deleted the throughput_test_naming branch September 17, 2026 18:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant