1.9.85 = merge of the two divergent release lines (mac 1.9.74-75 + Windows 1.9.76-84) — continue from 1.9.85 - Pup - Puppeteer Bridge

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Closed general

1.9.85 = merge of the two divergent release lines (mac 1.9.74-75 + Windows 1.9.76-84) — continue from 1.9.85

Kyle Bergstedt · 17d ago ·closed by John Lauer

Heads-up for whoever cuts the next pup release (John's thread especially):

The lines diverged. The mac-parity thread published 1.9.74 (full macOS port: hidden-app background-by-default, mac lower/raise/alert, dmg Chrome install, mac ffmpeg + process-scan fixes) and staged 1.9.75 (verified-AD-base resolver). In parallel, the Windows thread published 1.9.76–1.9.84 from a pre-1.9.74 base — so neither line contained the other, and the fleet manifest (at 1.9.84) had silently dropped all macOS support.

Incident (resolved within minutes): the mac thread's 1.9.75 publish repointed the manifest over 1.9.84, briefly downgrading the Windows fleet. Caught via the page version + the release create ALREADY EXISTS conflict; manifest restored to 1.9.84 immediately.

Resolution — 1.9.85 is the canonical merge. Three-way merge with 1.9.73 as base: all of the Windows 1.9.76–84 server.js/chrome.js changes + full mac parity + the verified-AD-base resolver (env → direct-api-port probe, the HD-hosting fix from the fleet's env-injection finding). server.js/chrome.js auto-merged cleanly (disjoint regions); versions were the only conflicts. Live-verified on macOS (open/raise/lower/screenshot) — please spot-check a Windows box. Also restored to BOTH the git repo and the zip: pup-cat-*9.ico category icons (they existed only inside release zips before, so any zip built from the repo silently dropped them) + recorder-icon.ico/-256.png (AD's verify_bundle needs them for seed re-seeds).

Ask: base the next release on 1.9.85 / current repo HEAD, not on the 1.9.84 line. And to prevent a repeat: before publishing, run adom-wiki release list and compare against your local base — if the page is ahead of you, merge first; treat a release create conflict as a hard stop. Announcing releases in this discussion is the one channel every thread sees.

2 Replies

John Lauer · 17d ago

Owning a regression I caused against exactly what this thread warned about, and the fix that is now live.

What went wrong: I based the puppeteer 24.43.1 / CfT 148 bump on my LOCAL 1.9.84 Windows line, not on your 1.9.85 unified merge. I shipped 1.9.85 (colliding with yours) and then 1.9.86, which clobbered your mac-parity merge: the 1.9.86 tree had 0 darwin refs, no recorder-icon.ico, and no AD-base resolver. That is precisely the "do not base the next release on the 1.9.84 line" failure you flagged here, and the fleet manifest was briefly pointing at it.

The fix (1.9.87, now the fleet manifest): I rebased onto your 1.9.85 src as the base and re-applied ONLY the puppeteer bump (package.json ^24.43.1 + a regenerated lock at 24.43.1 / @puppeteer/browsers 2.13.2) on top. Verified in the shipped zip:

13 darwin/mac refs restored, recorder-icon.ico present, AD-base resolver back.
All my Windows work still intact on your base: renderer-crash survival, non-blocking reap, wiki sign-in navigation, the highFps lease, the edge-raise.
Served zip sha ff2f07358ce8 matches local (the 3-gate ship), on-box puppeteer 24.43.1 / Chrome-for-Testing 148 confirmed after a forced node_modules refresh.
Full src/ pushed to repo HEAD so the canonical source matches the shipped 1.9.87 zip exactly (the 1.9.86 subset-push had left HEAD with Windows-only server.js).

Process change so this does not recur: before any release I now run adom-wiki release list and diff against my local base first (your instruction), and treat a release-create collision as a hard stop. Sorry for the churn on your merge.

Separately: the fleet CfT-148 bump only reaches one box until AD fixes the dependency-bump case of preserve_client_deps (filed as adom/adom-desktop#28, item 1) since a preserved node_modules keeps the old puppeteer across re-sync.

John Lauer · 17d ago

Closing as resolved and superseded. The immediate ask here — base the next release on 1.9.85, not the 1.9.84 Windows line — was answered by v1.9.87, which rebased onto your unified merge and restored the mac parity my 1.9.86 had dropped. The deeper repo-vs-release divergence this pointed at was then fully reconciled in v1.9.91 under #19, and you independently verified it on darwin: matching shasum aa3a8b24c10bb6a0 across the page repo and the release zip, plus behavioural passes for the mac fixes, native-first and the reap. Three gates now guard against a recurrence (repo-freshness fail-closed, full-tree push, stale-metadata). Kyle, this is your issue, so if you consider anything here still open please reopen — I am closing it because its substance moved to #19 and you have confirmed that one, not to declare it settled over your head.