chore(cli): deprecate event release mode on the mobile uploads

[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 #92401 ← this PR
• chore(gradle-plugin): deprecate event release mode posthog-android#747
• chore: deprecate POSTHOG_NO_RELEASE_BIND in the dsym upload posthog-ios#791

Making it the default.

• feat(cli): default release mode to event #91823 (stacked on this PR)
• 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 on the mobile uploads adds nothing: it pays off only when two releases ship a byte-identical artifact.
• A proguard map id is a hash of the mapping, and a dSYM symbol set is keyed on the Mach-O LC_UUID.
• An ordinary release that changes code gets its own symbol set and never collides.
• The dSYM path also lost release attribution for embedded targets. One upload covers every target's dSYM, but it creates one release.
• Removing the flags outright would break released callers. The Android gradle plugin and posthog-ios upload-symbols.sh still pass them, so an upgraded CLI would stop those builds with a parse error.

Changes

• proguard upload --release-mode and dsym upload --no-release-bind become hidden no-ops. Both commands always bind their symbol sets to the release they create.
• A build that still passes a flag keeps working. It prints a deprecation warning, and its opt-in unbinding stops.
• proguard upload no longer reads POSTHOG_RELEASE_MODE. The variable keeps steering the sourcemap and hermes commands, so a global symbol-set opt-out for those cannot trigger warnings here.
• --release-mode stays visible on sourcemap inject, sourcemap process, sourcemap upload, hermes inject, hermes clone and hermes upload.
• Mechanical: the shared conflict help now names the sourcemap and hermes uploads instead of "a command that takes --release-mode", because proguard now takes it invisibly.

How did you test this code?

• New parse tests pin the compatibility contract: both flags parse and default off, stay out of --help, and --release-mode binds no environment variable. They catch a future re-removal, which is the build break this PR prevents.
• A local run with --release-mode event printed the warning and kept the release binding.
• Not run: an upload against a real project.

Automatic notifications

• Publish to changelog?

Docs update

None. Both knobs were experimental and undocumented.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Claude Code (Opus 5); reshaped from removal to deprecation with Claude Code (Fable 5). Skills invoked: /writing-pr-descriptions.

Reviews here and on PostHog/posthog-android#747 and PostHog/posthog-ios#791 asked for warned no-ops instead of removal. #91823 stacks on this PR and flips the defaults for the commands that keep the flag.

[trunk-io]

😎 Stack merged successfully - details.

[github-actions]

🤖 CI report

✅ Trunk lane — non-backend lane

This PR is assigned to the non-backend lane. It does not run backend Python tests and may merge in parallel with PRs in other lanes.

[posthog]

🦔 PostHog Review reviewed this pull request

Found 0 must fix, 4 should fix, 0 consider.

Published 4 findings (view the review).

Resolved comments: 1 fixed, 1 declined, 2 left for you

[posthog]

PostHog Review alpha 🦔 If you find any issues helpful - please reply "valid", "invalid", etc., for evaluation purposes 🙏

[posthog]

PostHog Review

Found 4 should fix.

[greptile-apps]

_{Reviews (1): Last reviewed commit: "chore(cli): drop the proguard upload tes..." | Re-trigger Greptile}

[Copilot]

Pull request overview

Removes the experimental “event release mode” controls from the mobile debug-symbol upload commands in the Rust CLI, standardizing proguard upload and dsym upload on binding uploaded symbol sets to the release they create.

Changes:

• Remove --release-mode from proguard upload and always set release_id on the uploaded mapping (when a release is created).
• Remove --no-release-bind from dsym upload and always set release_id on uploaded dSYM chunks.
• Update shared conflict-flag help text and add a CLI changeset describing the behavior change.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
cli/src/sourcemaps/args.rs	Updates help text for shared upload conflict flags.
cli/src/proguard/upload.rs	Drops --release-mode support and always attempts to bind proguard mappings to the created release.
cli/src/dsym/upload.rs	Drops --no-release-bind and always binds dSYM chunks to the created release.
cli/.sampo/changesets/remove-mobile-release-mode.md	Adds release notes for the CLI behavior/flag removal.

Suppressed comments (1)

cli/src/sourcemaps/args.rs:145

• Similarly, the --skip-on-conflict help text mentions “a sourcemap upload” and --release-mode=event, but this arg struct is reused by other commands that don’t support --release-mode. Rewording to describe the behavior without tying it to a specific subcommand/flag will avoid confusing CLI help across commands.

    /// Skip symbol sets that already exist with different content instead of failing.
    /// Existing symbol sets are left unchanged. A sourcemap upload ignores this with
    /// `--release-mode=event`. [default: false]

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-09-02 12:46 UTC	Run
prod-us	✅ Deployed	2026-09-03 08:35 UTC	Run
prod-eu	✅ Deployed	2026-09-03 08:36 UTC	Run