LH034 checkpoint, 27 October 2026: baseline

Working record, unreviewed. The brief was committed at 18:11:01 UTC (e338e72; its header's "about 18:15" was the writer's estimate). Read data/read-2026-10-27T1811Z, started 18:11 UTC: dist/index.json and 65 daily summaries (28 July to 27 August and 23 September to 26 October 2026), all HTTP 200. Tables: data/tables.json (scripts/tabulate.py). Days 0 to 5 are complete (21 to 26 October).

One reading of the brief, made after the version table's key names were listed and before any count was read: the table carries a key unknown, which is counted with the requests that have no version, not as a release line (scripts/tabulate.py, docstring).

Measure 1: share of each fixed line's nodejs.org downloads at or above the fixed release (observation, derived share)

All three lines first passed half on day 2. Day 0 is the day the binaries were posted, about 10:32 to 10:36 by the /dist/ listings, so it is a part day. Days 3 and 4 were a Saturday and Sunday, with about half the weekday volume. Each share counts requests in a day; it is not a count of machines, and nodejs.org is one channel of several (brief, Source).

Measure 2: downloads from lines the release does not fix (observation, derived share)

From 11.8 to 16.5 per cent of version-attributed downloads each day from 18 to 26 October, 14.3 per cent on day 0 and 12.5 per cent on day 5. Line 20, which has reached end of life, was 5.8 to 8.5 per cent, and line 25, also at end of life, 0.7 to 1.1 per cent. Requests with no version, the unknown key included, were at most 0.01 per cent of total.

Measure 4: the July 2026 security release, same instrument (observation, derived share)

Day 0 is 28 July, the date dist/index.json gives v26.5.1, as the brief fixed. The /dist/ listings show the July files posted on 29 July (13:55, 16:11 and 14:01 for v22.23.2, v24.18.1 and v26.5.1), so the July series runs about a day ahead of posting: its day 1 is the posting day, as October's day 0 is. That offset was not known when the rule was fixed.

The July series moves by up to about 20 points from one day to the next in lines 22 and 24 (24 at 57.2 per cent on day 5 and 29.4 on day 7), so a single day is a weak summary of it.

Beside the Python figures and the PHP fix (derived; described only)

• Python, same unit, different index: LH008's four security fixes held 53.8 to 60.8 per cent of their library's downloads on day 1 and 52.7 to 63.7 per cent on day 2; the median of the 37 projects' medians was 57.6 and 57.2 per cent. On day 1, each Node line (41 to 46 per cent) was below the Python fixes' range; on day 2, line 22 (51.7) was just below it, and lines 24 (72.4) and 26 (79.7) above it.
• PHP, different unit, same day 0: LH033 has Censys's patched share for PHP 8.2 to 8.5 at 22 to 36 per cent on day 1 and 41 to 71 per cent on day 2, as standing services last rescanned. A request share and a service share are different quantities; they are set beside each other, not compared as rates.
• Node, the July release: by the brief's rule, each October line's day 1 and day 2 shares were above July's, by 21 to 57 points in lines 22 and 24 and by 4 to 10 points in line 26. Aligned by posting day instead, a post hoc reading made here after both series were seen (one comparison, not in the brief): July's lines 22, 24 and 26 held 30.7, 15.1 and 69.9 per cent the day after posting, where October's held 41.0, 45.8 and 45.4; five days after posting, 33.2, 45.9 and 89.7 against 52.7, 69.3 and 61.5. No cause is read into any difference; the October release came on the same day as PHP's emergency release and with more press, and July's did not, but this study measures neither.

Not checked

The build code that writes the summaries; whether the summaries' day is UTC; how much of a day's requests come from CI systems fetching the same version repeatedly; whether a re-read of days 0 to 7 matches (due with the day-30 read).