deploy: robust cross-OS releases (Windows/Linux/macOS) by next Epoch

[PipFoweraker]

Pip ruling 2026-07-26: deployments must be robust across OSs by the next Epoch.

Evidence from the v0.13.1 release (2026-07-26)

• The Enhanced Release CI workflow now builds all 3 platforms on tag push (new since v0.13.0), but packages ONLY exe+pck: no gdextension binaries (godotsteam), no HOW-TO-RUN.txt. Verified on Windows: game boots but GDExtension fails to load (3 errors) and Steam integration is silently dead.
• v0.13.1 Windows assets were hand-replaced with a complete, stamp-verified local build under the CI's canonical names. Linux zip patched with its .so. macOS .app untested/unverified.
• Pre-Release Checks workflow fails on missing CHANGELOG entry (process gap, being fixed).

Definition of robust (proposed)

1. CI packaging includes per-platform gdextension binaries + HOW-TO-RUN.txt (immediate fix in flight).
2. Boot-test matrix: each platform zip verified to launch to menu (manual friend-confirmations first -- macOS + Debian testers standing by; automate headless boot smoke later).
3. Release notes carry honest per-platform test status ('boots on X, not extensively tested') until a platform graduates.
4. Signing/trust posture documented per platform (SmartScreen / Gatekeeper unidentified-developer / chmod +x).
5. RELEASE_CHECKLIST.md covers all platforms; Pre-Release Checks green on tag.

Related: #775 (release-branch model), the launch packaging notes (zip-extract trap), today's session findings.

🤖 Generated with Claude Code

[PipFoweraker]

First real-world confirmation, from a funder, on 2026-07-29

This issue predicted the macOS trust posture would bite (definition-of-robust item 4, "Gatekeeper unidentified-developer"), and item 3's honesty requirement ("macOS .app untested/unverified"). Both just landed at once, in public, on the Manifund application page.

Austin Chen, while making a $1,000 donation:

"I wasn't actually able to demo the game myself -- I'm on Mac, Sequoia 15.5, and 'right click => open' only gave me 'cancel' and 'move to trash' as options. (Vaguely I think that I've solved this problem before for other apps, but it was enough of a roadblock for me to give up)."

Why "right click => open" failed specifically

That was the standard Gatekeeper bypass for unsigned apps for about a decade. Apple removed it in macOS Sequoia (15.x). Unsigned apps there must be approved via System Settings -> Privacy & Security -> "Open Anyway" after a first blocked launch attempt, or have the quarantine attribute stripped with xattr -dr com.apple.quarantine.

So this is not a broken build -- the .app may well be fine. It is a documentation and trust-posture failure, and the specific instruction people would reach for by habit is now dead on current macOS.

Two compounding problems found while checking this

1. PDoom-macOS-v0.13.1.zip has 6 downloads, and PDoom.app.zip another 3 -- so people ARE taking the macOS build. Meanwhile README.md said, verbatim: "Linux and macOS builds are not published yet." Mac users were downloading a build the project told them did not exist, then hitting a wall with no guidance anywhere.

2. The README's Windows download link was a 404. It pointed at releases/latest/download/PDoom.exe, and no such asset exists -- the assets are PDoom-Windows-v0.13.1.zip / PDoom-Windows.zip. Verified: curl returns 404 for PDoom.exe, 200 for the real names.

Both fixed in the README PR referencing this issue. The README now carries per-platform first-launch instructions including the Sequoia path, and honest per-platform test status per item 3.

What remains open here

Documentation reduces the friction; it does not remove it. Signing and notarization (#683 for the secrets) is still the actual fix, and it now has a concrete cost attached: a funder gave up before playing.

Also worth noting -- asset naming is doubled

The latest release ships BOTH versioned and unversioned names for two platforms (PDoom-Windows-v0.13.1.zip + PDoom-Windows.zip; PDoom-macOS-v0.13.1.zip + PDoom.app.zip) but only a versioned name for Linux. Two naming schemes side by side is the same hand-maintained-pointer family as #1008 and #963/#998, and it makes any direct-link documentation fragile. Worth settling on one scheme as part of "robust".