chore(gradle-plugin): deprecate event release mode by ablaszkiewicz · Pull Request #747 · PostHog/posthog-android

ablaszkiewicz · 2026-09-01T11:41:50Z

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.

Making it the default.

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.

The plugin uploads the proguard mapping bound to the release it creates. The map id is a content hash of the mapping, so two releases collide only when they ship a byte-identical mapping. An ordinary release that changes code already gets its own symbol set. The property was experimental and undocumented. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jg6r6rFUBnowrXssZyU7yR

posthog · 2026-09-01T12:36:59Z

🦔 PostHog Review reviewed this pull request

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

greptile-apps · 2026-09-01T13:40:30Z

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}

An Exec task inherits the daemon environment, and posthog-cli reads POSTHOG_RELEASE_MODE for proguard upload. A value set for another tool would leave the mapping release-independent, which is what this PR removes. A posthog-cli without the flag ignores the variable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jg6r6rFUBnowrXssZyU7yR

marandaneto · 2026-09-01T13:44:59Z

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

Review asked for deprecation instead of removal, so upgrading cannot silently change a configured build. The posthog.releaseMode property and the task's releaseMode input stay accepted, warn, and do nothing. The POSTHOG_RELEASE_MODE environment variable stays silent because it still steers other PostHog tools. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0177eam86deHk8HZYMKcJtbD

ablaszkiewicz · 2026-09-01T15:35:26Z

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

turnipdabeets · 2026-09-01T19:45:55Z

+        // POSTHOG_RELEASE_MODE for `proguard upload`, and an Exec task inherits the daemon
+        // environment, so a value set for another tool would otherwise leave the mapping
+        // release-independent. Pin it. A posthog-cli that has no such flag ignores the variable.
+        environment("POSTHOG_RELEASE_MODE", "symbol-set")


[question] Pinning this is the right call for the inherited-env case. One gap though: POSTHOG_RELEASE_MODE=event used to select event mode too, so a CI job that set it there gets its mappings bound to a release again with no warning at all — the gradle property path warns, this one doesn't. Could we warn when the inherited value isn't symbol-set, worded so it doesn't ask people to unset it (it still steers sourcemap and hermes)?

turnipdabeets · 2026-09-01T19:45:55Z

            extension.uploadNativeSymbols.convention(false)
            extension.includeNativeSymbolSources.convention(false)

+            warnIfDeprecatedReleaseModeSet(project)


[suggestion] This runs at configuration time, so with the configuration cache it prints on the first build and never again on a reused entry — and Gradle 9 turns that on by default. If we also set the property's value on the upload task's releaseMode, the execution-time warning fires every build instead. NativeSymbolsUploadFunctionalTest already builds a real app with --configuration-cache and asserts on the output, so it's a short test there.

turnipdabeets · 2026-09-01T19:45:55Z

+        }
+
+        // The mapping always binds to the release this build creates. posthog-cli reads
+        // POSTHOG_RELEASE_MODE for `proguard upload`, and an Exec task inherits the daemon


[nit] PostHog/posthog#92401 removes env = "POSTHOG_RELEASE_MODE" from proguard upload, so this stops being true once that ships and the pin only covers CLI 0.12.0 up to that release. Worth naming that window here so we know when it can go.

ablaszkiewicz self-assigned this Sep 1, 2026

This was referenced Sep 1, 2026

feat(cli): default release mode to event PostHog/posthog#91823

Open

feat(plugins): default release mode to event PostHog/posthog-js#4705

Open

ablaszkiewicz requested review from a team, cat-ph and hpouillot September 1, 2026 13:38

ablaszkiewicz marked this pull request as ready for review September 1, 2026 13:38

ablaszkiewicz requested a review from a team as a code owner September 1, 2026 13:38

greptile-apps Bot reviewed Sep 1, 2026

View reviewed changes

Comment thread ...droid-gradle-plugin/src/main/kotlin/com/posthog/android/PostHogUploadProguardMappingsTask.kt

ablaszkiewicz changed the title ~~chore(gradle-plugin): remove event release mode~~ chore(gradle-plugin): deprecate event release mode Sep 1, 2026

turnipdabeets reviewed Sep 1, 2026

View reviewed changes

turnipdabeets requested a review from a team September 1, 2026 19:46

Navigation Menu

Uh oh!

chore(gradle-plugin): deprecate event release mode - #747

chore(gradle-plugin): deprecate event release mode#747
ablaszkiewicz wants to merge 3 commits into
mainfrom
chore/remove-event-release-mode

ablaszkiewicz commented Sep 1, 2026 •

edited

Loading

Uh oh!

posthog Bot commented Sep 1, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Sep 1, 2026

Uh oh!

Uh oh!

marandaneto commented Sep 1, 2026

Uh oh!

ablaszkiewicz commented Sep 1, 2026

Uh oh!

turnipdabeets Sep 1, 2026

Uh oh!

turnipdabeets Sep 1, 2026

Uh oh!

turnipdabeets Sep 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ablaszkiewicz commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related PRs

Problem

Changes

How did you test this code?

🤖 Agent context

Uh oh!

posthog Bot commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦔 PostHog Review reviewed this pull request

Uh oh!

greptile-apps Bot commented Sep 1, 2026

Uh oh!

Uh oh!

marandaneto commented Sep 1, 2026

Uh oh!

ablaszkiewicz commented Sep 1, 2026

Uh oh!

turnipdabeets Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

turnipdabeets Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

turnipdabeets Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ablaszkiewicz commented Sep 1, 2026 •

edited

Loading

posthog Bot commented Sep 1, 2026 •

edited

Loading