[dylanjeffers]

Problem

The desktop app has not updated since Aug 3.

Desktop has two update paths, and both need a newer version than the one installed:

• Web update (checkForWebUpdate in packages/web/src/electron.js): polls s3://audius.co/package.json every minute and only downloads build-production.tar.gz when the marker has the same major.minor and a strictly higher patch.
• Full app update (electron-updater): reads download.audius.co/latest*.yml and only installs a higher version.

Nothing bumps packages/web/package.json per release. It has been 1.5.180 since Version Packages #14216 (2026-08-03). The open Version Packages PR (#14609) doesn't touch web either, because no changeset names @audius/web. Every production approval since then has published version 1.5.180:

• s3://audius.co/package.json was last written 2026-11-03 and says 1.5.180.
• latest*.yml says 1.5.180, and the Mac build was re-released 2026-11-03 under the same version.

So a desktop install on 1.5.180 sees nothing newer and keeps whatever web bundle it installed, anywhere from Aug to Nov. This is also why desktop users were still hitting the old 500 MB upload cap long after the 2 GB change.

Fix

production-gate now picks the release version after approval:

next = patch + 1 of max(packages/web/package.json, published s3://audius.co/package.json)

web-deploy and the Mac/Windows/Linux desktop jobs write that version into packages/web/package.json and build-production/package.json before packaging. That keeps the S3 marker, the web-update tarball, the electron-updater feeds and the app's own appVersion on the same number. The Slack messages report it too.

Why after approval: runs wait at the gate for days and get approved out of order. A version picked at build time would give every waiting run the same number.

Nothing changes on the client. The S3 layout is the same (packages/web/ prefix in the tar, package.json inside build-production/). An old client only understands "higher patch", and that's what it gets.

How existing 1.5.180 installs pick it up

The next approved production run publishes 1.5.181 (checked against the live marker: repo 1.5.180, published 1.5.180 → 1.5.181).

• Running 1.5.180 apps see the 1.5.181 marker within a minute and download the bundle. The web update banner appears (patch bumps are below MIN_APP_VERSION, so it's the soft banner), and accepting it reloads into the current web build.
• electron-updater also sees 1.5.181 in latest*.yml on next launch, downloads the full app, and installs it on quit. That path is silent for patch bumps.
• Every later approval goes to 1.5.182, 1.5.183, and so on, so this can't freeze again.

Confirmed on a real install

On a Mac desktop install from Aug 18:

• /Applications/Audius.app is 1.5.180.
• ~/Library/Application Support/Audius/build-production/package.json is also 1.5.180, so getNewestBuildDirectory keeps loading the bundled Aug 18 build.
• The S3 marker is 1.5.180, so checkForWebUpdate never fires.
• The bundled app.asar has none of the flags added after Aug 18 (track_tile_waveform, now_playing_comments).

Verify after the next approval

1. curl -s https://s3.us-west-1.amazonaws.com/audius.co/package.json | jq -r .version prints 1.5.181, and the Pick release version step in the gate job logs the same number.
2. Leave that 1.5.180 desktop app open for a minute and the web update banner appears. Accept it, then check that ~/Library/Application Support/Audius/build-production/package.json is 1.5.181.
3. Quit and relaunch, and electron-updater installs the 1.5.181 app.

Notes

• The repo version stays the floor. A manual bump, or a minor bump for a forced full update, still wins over the published marker.
• If two runs are approved within minutes of each other, both can pick the same number before either writes the marker. The second tarball then overwrites the first at that version, and clients that already took the first wait one more release. This only matters for near-simultaneous approvals, so I didn't add locking.
• The web bundle's embedded version (Optimizely appVersion, analytics, the settings page) still comes from the repo package.json at build time, because the build runs before the gate. Only the update markers and desktop app versions are stamped.
• actionlint is clean. I ran the version-pick script locally against the live S3 marker.

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: c941832

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[socket-security]

Dependency limit exceeded — report not shown.

This pull request scan exceeded the 10,000-dependency limit applied to this scan, so the results are incomplete and may be inaccurate. To avoid reporting false positives, Socket has not posted a report.

Upgrade your plan to raise the dependency limit and get complete reports, or view the partial scan in the dashboard.

Socket is always free for open source. If this is a non-commercial open source project, contact us to request a free Team account.