fix: pick the highest Chromium version in a milestone, not the most recent release

[claude]

Requested by David Babenko-Sanders · Slack thread

The roller picks a release branch's roll target as the last entry from chromiumdash for that branch's milestone, but it sorted those entries by release time. Channels and platforms within a milestone ship on their own schedules, so the newest release is not always the newest version: for Chromium 156 (45-x-y), the Extended build 156.0.8078.13 went out a couple of hours after the Windows Beta builds 156.0.8078.16 and .17, so time ordering held the branch at .13. Releases are now sorted by version with compareChromiumVersions, so the roller always targets the highest version published for the milestone (and, for main, the highest Canary build). This also gives a deterministic pick when several channels publish at the same timestamp, as Extended .36, Stable .36 and early-Stable .35 did this week. I could not query chromiumdash directly from the sandbox, so the timeline above comes from the VersionHistory API, which tracks the same releases.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PbwafMAXGvxSbV7VWbwGus

---

Generated by Claude Code

[claude]

LGTM — straightforward fix that swaps release-time sorting for version-based sorting via the existing, unmodified compareChromiumVersions helper.

What was reviewed: the sort-key change in getChromiumReleases and its interaction with the downstream consumer in src/chromium-handler.ts (confirmed it still takes the array's last/highest entry as the roll target); the new test file's four cases (version-overrides-time ordering, numeric vs lexicographic comparison, query-param pass-through, error-on-non-200). Ruled out: malformed/non-numeric version strings causing silent miscomparison — this risk lives in the pre-existing, unmodified compareChromiumVersions helper, not in this diff.

Extended reasoning...

Two-file diff: a one-line sort-key swap in src/utils/get-chromium-tags.ts (time -> compareChromiumVersions, an existing unmodified helper) plus a new 92-line test file covering the behavior change. No security-sensitive surface (no auth, crypto, or permissions); touches only a Chromium-release-ordering utility used by the internal roller. Verified the downstream consumer (src/chromium-handler.ts) still takes the last array entry as the roll target, consistent with the new ascending-version sort, and that tests exercise the key scenarios described in the PR.