chore(gradle-plugin): deprecate event release mode

[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 #747 ← this PR
• chore: deprecate POSTHOG_NO_RELEASE_BIND in the dsym upload posthog-ios#791

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 mapping.
• The map id is already a content hash of the mapping, so a release that changes code gets its own symbol set.
• An ordinary release therefore never collides with an earlier one, and the mode adds nothing.
• Removing the property outright would silently flip a configured build to binding, with nothing in the build output saying so.

Changes

• A build that sets posthog.releaseMode keeps building and gets a deprecation warning. The value is ignored, and the mapping uploads bound to the release the build creates.
• The upload task keeps its public releaseMode input as a @Deprecated no-op, so a build script that configures the task does not break. Setting it warns at execution.
• The POSTHOG_RELEASE_MODE environment variable no longer reaches the upload. The task pins symbol-set into the posthog-cli child environment, so an inherited value cannot unbind the mapping on an older CLI.
• The plugin stays silent about the environment variable on purpose. It still steers the sourcemap and hermes uploads of other PostHog tools, so a warning about it would not be actionable.
• PostHogReleaseMode and the mode plumbing stay removed. Only the warning path reads the property now.

How did you test this code?

• ./gradlew :posthog-android-gradle-plugin:test spotlessCheck detekt passes.
• The warning paths have no test. The module has no Project or Exec harness, and building one for two log lines does not earn its cost.

🤖 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.

This replaces #739. The reshape answers the review comment asking that upgrading must not break or silently change configured builds. PostHog/posthog#92401 keeps proguard upload --release-mode parseable on the CLI side, which covers a build that upgrades the CLI before this plugin.

[posthog]

🦔 PostHog Review reviewed this pull request

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

[greptile-apps]

Prompt To Fix All With AI

### Issue 1
posthog-android-gradle-plugin/src/main/kotlin/com/posthog/android/PostHogUploadProguardMappingsTask.kt:60
**Inherited release mode remains active**

If the Gradle daemon or CI environment has `POSTHOG_RELEASE_MODE=event`, this task still passes that inherited variable to `posthog-cli` without an overriding argument, causing the mapping to remain release-independent instead of being bound to the release as documented.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "chore(gradle-plugin): remove event relea..." | Re-trigger Greptile}

[marandaneto]

if people set those, this will break their builds
instead, deprecate the config and mention its a no-op, and remove the behaviour, but upgrading should not break peoples build
or, bump a major

[ablaszkiewicz]

@marandaneto deprecated it instead of getting rid of it as you suggested. May I get a re-review?

[marandaneto]

approving to unblock but see comments first