Pin com.posthog:posthog-android instead of using open version range [3.38.0,4.0.0) #377

Summary

posthog_flutter declares its native Android SDK dependency as an open version range:

// posthog_flutter-5.23.1/android/build.gradle
implementation 'com.posthog:posthog-android:[3.38.0,4.0.0)'

This is non-deterministic — Gradle resolves to whatever posthog-android patch is latest at build time. For any consumer that needs reproducible builds across short time windows (CI matrix re-runs, hotfix patch builds, regulated release pipelines), this is a footgun. Plugin pubspec versions are pinned (posthog_flutter: 5.23.1), but the native dep silently drifts.

Concrete impact: shorebird patches break

We use Shorebird for Dart-only OTA patches. Shorebird verifies that a patch build's native artifacts are byte-identical to the release artifact — any native diff aborts the patch with UnpatchableChangeException.

Released 0.148.1+9 on 2026-04-24 with com.posthog:posthog-android:3.42.1 (whatever Gradle resolved to that day). Tried to ship a Dart-only hotfix on 2026-04-27 — Gradle resolved to 3.43.0 (PostHog published it in the meantime), and shorebird rejected the patch:

[WARN] Your app contains native changes, which cannot be applied with a patch.
    Changed files:
        base/dex/classes.dex
Breaking differences (2):
  - com.posthog.PostHogConfig: bytecode changed in <init>(Ljava/lang/String;, Ljava/lang/String;)V
  - com.posthog.android.PostHogAndroid: bytecode changed in a(Landroid/content/Context;, ...)V

Both classes embed a sdkVersion constant from BuildConfig.VERSION_NAME, which differs between 3.42.1 and 3.43.0 — pure version drift, no source change on our side.

Workaround we shipped

Pin in app build.gradle.kts:

dependencies {
    constraints {
        implementation("com.posthog:posthog-android:3.42.1") {
            because("posthog_flutter ships an open range; pin so shorebird patches dex-match the release")
        }
    }
}

This unblocks us, but every consumer hits this independently and most won't know to look.

Ask

Pin to an exact posthog-android version per posthog_flutter release:

implementation 'com.posthog:posthog-android:3.x.y'  // exact, bumped intentionally per posthog_flutter release

This is the convention nearly every other Flutter plugin follows (e.g. firebase_*, google_sign_in, auth0_flutter) precisely so the unit of upgrade is the Flutter plugin version, not "whatever happens to be on Maven today." Open ranges trade upstream agility for consumer reproducibility — the trade-off doesn't favor consumers, especially for SDKs whose bytecode bakes in version constants.

If exact pinning is undesirable, even a narrow range (3.42.x) would let consumers pin transitively without surprises.

Environment

• posthog_flutter: 5.23.1
• Flutter: 3.41.6
• AGP: (Flutter default for this version)
• Affected posthog-android versions: any pair where the patch number differs (saw 3.42.1 → 3.43.0)

Happy to send a PR if there's appetite for the change.