chore: deprecate POSTHOG_NO_RELEASE_BIND in the dsym upload

[ablaszkiewicz]

Related PRs

Event mode is live today, and it is opt-in. These PRs settle where it stays and where it goes.

Deprecating the mobile knobs. The symbol id on these paths is already a content hash, so two releases collide only when they ship a byte-identical artifact. An ordinary release that changes code gets its own symbol set and never collides. The dSYM path also lost release attribution for embedded targets, because one upload covers every target while it creates one release. Review asked for deprecation instead of removal, so every knob stays accepted as a warned no-op.

• chore(cli): deprecate event release mode on the mobile uploads posthog#92401
• chore(gradle-plugin): deprecate event release mode posthog-android#747
• chore: deprecate POSTHOG_NO_RELEASE_BIND in the dsym upload #791 ← this PR

Making it the default.

• feat(cli): default release mode to event posthog#91823 (stacked on chore(cli): deprecate event release mode on the mobile uploads posthog#92401)
• feat(plugins): default release mode to event posthog-js#4705

React Native. Scopes the mode to the Hermes upload and defaults it to event. That is the one path where two releases really do ship the same artifact.

• feat(react-native): scope event release mode to the Hermes upload posthog-js#4717

Problem

• Event mode helps only when two releases ship a byte-identical binary. The symbol id is the Mach-O LC_UUID.
• The unbound path also lost release attribution for embedded targets.
• The upload covers every extension dSYM, but it creates one release, from PRODUCT_BUNDLE_IDENTIFIER.
• An extension reports its own bundle identifier as $app_namespace, so its crashes matched no release.
• A silent removal would leave an opted-in user with no signal that their dSYMs bind again.

Changes

• A build that sets POSTHOG_NO_RELEASE_BIND sees a build-log warning naming the deprecation and the fix. The script ignores the variable and uploads symbol sets bound to the release it creates.
• dsym upload no longer receives --no-release-bind.
• The script header documents the variable as deprecated instead of dropping it.
• The posthog-cli floor returns to 0.7.7, or 0.7.12 with POSTHOG_SKIP_ON_CONFLICT.

How did you test this code?

• bash build-tools/upload-symbols.test.sh passes.
• A new case sets the variable and asserts the warning prints, the upload succeeds, and --no-release-bind is not forwarded. It catches the flag forwarding coming back, which would fail the Xcode phase against a CLI that removes the flag for real.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Claude Code (Opus 5); the warning added with Claude Code (Fable 5) per the review comment. Skills invoked: /writing-pr-descriptions, /writing-tests.

This replaces #789. That PR also carried a fix for a zero-padded CFBundleVersion, which follows in a separate PR. PostHog/posthog#92401 keeps dsym upload --no-release-bind parseable as a hidden no-op, which covers a build that upgrades the CLI before this pod.

[posthog]

🦔 PostHog Review reviewed this pull request

Nothing worth raising this time, so here's a calming picture instead:

[greptile-apps]

_{Reviews (1): Last reviewed commit: "chore: remove POSTHOG_NO_RELEASE_BIND fr..." | Re-trigger Greptile}

[marandaneto]

print a deprecate/no-op warning if POSTHOG_NO_RELEASE_BIND is set so people know about this after upgrading

[ablaszkiewicz]

@marandaneto deprecated it instead of getting rid of it as you suggested