feat(flags): support semver targeting in feature flags UI

[dmarticus]

Problem

With #44598 and #44596, we'll have backend support for supporting creating flags that will target semver-like string properties (such as e.g. $app_version); this change implements UI support for creating these rules. Together, these 3 PRs will close #24485

Users need to be able to:

• Select semver operators from the property filter dropdown
• Create version-based targeting rules through the UI
• See clearly which operators are semver-specific vs. regular
  string comparisons

Changes

Frontend UI Updates

Added semver operators to string property filters:

• Added 7 semver operators to stringOperatorMap so they appear alongside regular string operators
• Operators are clearly labeled with (semver) prefix for easy identification:
• > (semver) greater than
• ≥ (semver) greater than or equal
• < (semver) less than
• ≤ (semver) less than or equal
• ~ (semver) tilde range
• ^ (semver) caret range
• * (semver) wildcard

Type system updates (frontend/src/types.ts):

• Added Semver to PropertyType enum
• Already had semver operator types (SemverGt, SemverGte,
  etc.) from backend work

Utility functions (frontend/src/lib/utils.tsx):

• Added isOperatorSemver() helper function for
  detecting semver operators
• Added Semver to operatorMappingChoice type mapping
• Created semverOperatorMap with human-readable labels

Future work (frontend/src/lib/components/PropertyFilters/co mponents/PropertyValue.tsx:82-84):

• Added TODO comment for semver input validation (validate format like "1.2.3")

How did you test this code?

Manual Testing

1. Navigated to Feature Flags → Create new flag → Add condition
2. Selected a string property (e.g., $app_version)
3. Verified semver operators appear in operator dropdown
   with clear (semver) labels
4. Selected > (semver) greater than operator
5. Entered test value 1.2.0
6. Verified the filter saves correctly and displays the
   semver operator in the UI
7. Tested multiple operators to ensure all 7 appear and are
   selectable

Expected User Experience

When creating a feature flag targeting rule:

1. User selects any string property (e.g., app_version,
   $lib_version)
2. Operator dropdown shows both regular string operators AND semver operators
3. Semver operators are clearly labeled with (semver) postfix
4. User can select and use semver operators just like any other operator
5. The backend (already implemented) handles the semver comparison logic

Publish to changelog?

Feature flag targeting now supports semantic versioning
operators (>, ≥, <, ≤, ~, ^, *) for version-based rollouts.

[github-actions]

Migration SQL Changes

Hey 👋, we've detected some migrations on this PR. Here's the SQL output for each migration, make sure they make sense:

posthog/migrations/0963_add_azure_blob_destination.py

BEGIN;
--
-- Alter field type on batchexportdestination
--
-- (no-op)
--
-- Alter field kind on integration
--
-- (no-op)
COMMIT;

posthog/migrations/0964_webauthncredential.py

BEGIN;
--
-- Create model WebauthnCredential
--
CREATE TABLE "posthog_webauthncredential" ("id" uuid NOT NULL PRIMARY KEY, "credential_id" bytea NOT NULL, "label" varchar(200) NOT NULL, "public_key" bytea NOT NULL, "algorithm" integer NOT NULL, "counter" integer NOT NULL, "transports" jsonb NOT NULL, "verified" boolean NOT NULL, "created_at" timestamp with time zone NOT NULL, "user_id" integer NOT NULL);
ALTER TABLE "posthog_webauthncredential" ADD CONSTRAINT "posthog_webauthncredential_user_id_credential_id_f5f4aa80_uniq" UNIQUE ("user_id", "credential_id");
ALTER TABLE "posthog_webauthncredential" ADD CONSTRAINT "posthog_webauthncredential_user_id_7509f37d_fk_posthog_user_id" FOREIGN KEY ("user_id") REFERENCES "posthog_user" ("id") DEFERRABLE INITIALLY DEFERRED;
CREATE INDEX "posthog_webauthncredential_user_id_7509f37d" ON "posthog_webauthncredential" ("user_id");
COMMIT;

posthog/migrations/0967_oauth_dcr_fields.py

BEGIN;
--
-- Add field dcr_client_id_issued_at to oauthapplication
--
ALTER TABLE "posthog_oauthapplication" ADD COLUMN "dcr_client_id_issued_at" timestamp with time zone NULL;
--
-- Add field is_dcr_client to oauthapplication
--
ALTER TABLE "posthog_oauthapplication" ADD COLUMN "is_dcr_client" boolean DEFAULT false NOT NULL;
ALTER TABLE "posthog_oauthapplication" ALTER COLUMN "is_dcr_client" DROP DEFAULT;
COMMIT;

posthog/migrations/0969_add_oauth_is_verified.py

BEGIN;
--
-- Add field is_verified to oauthapplication
--
ALTER TABLE "posthog_oauthapplication" ADD COLUMN "is_verified" boolean DEFAULT false NOT NULL;
ALTER TABLE "posthog_oauthapplication" ALTER COLUMN "is_verified" DROP DEFAULT;
COMMIT;

Last updated: 2026-01-11 18:56 UTC (6a38fef)

[github-actions]

❌ Hobby deploy smoke test: FAILED

Failing fast because: Timed out after 45 minutes

Connection errors: 174
HTTP 502 count: 0
Last error: ConnectionError

---

_{Run 20900072219 | Consecutive failures: 1}

[cubic-dev-ai]

1 issue found across 3 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="frontend/src/lib/utils.tsx">

<violation number="1" location="frontend/src/lib/utils.tsx:425">
P1: Missing `PropertyOperator.SemverEq` in the semver operator check. The `semverOperatorMap` includes `semver_eq`, and `PropertyOperator.SemverEq` exists in the types, but this function doesn't check for it.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[greptile-apps]

Greptile Summary

This PR adds UI support for semantic versioning operators in feature flag targeting, enabling users to create version-based rollout rules (e.g., target users with $app_version > 1.2.0).

Changes Overview

Type System (types.ts):

• Added Semver to PropertyType enum to support explicit semver typing

Operator Maps (utils.tsx):

• Added 7 semver operators to stringOperatorMap with "(semver)" labels so they appear for string properties
• Added Semver to operatorMappingChoice mapping
• Added isOperatorSemver() helper function
• Reordered spreads in allOperatorsMapping to ensure "(semver)" suffix labels are used

Property Value Component (PropertyValue.tsx):

• Added TODO comment for future semver input validation

Critical Issues Found

1. Missing semver_eq operator (Logic Bug)

The stringOperatorMap only includes 7 semver operators but is missing semver_eq: '= equals (semver)'. The backend supports all 8 semver operators including SemverEq, and semverOperatorMap (line 340) includes it. Users will be unable to perform semantic version equality checks (e.g., matching "1.0.0" with "1.0") on string properties.

2. Incomplete isOperatorSemver() function (Logic Bug)

The helper function checks for 7 operators but is missing PropertyOperator.SemverEq. This will cause incorrect behavior when code calls this function to determine if an operator is semver-related.

3. Duplicate operator definitions (Style Issue)

Semver operator keys now exist in BOTH stringOperatorMap (with "(semver)" suffix) and semverOperatorMap (without suffix). When spread into allOperatorsMapping, this creates potential inconsistency - properties typed as PropertyType.Semver will show different labels than those accessed through allOperatorsMapping. Consider consolidating to a single source of truth.

Design Notes

The PR takes an interesting approach by adding semver operators to stringOperatorMap rather than requiring properties to be explicitly typed as PropertyType.Semver. This allows users to use semver operators on any string property (like $app_version, $lib_version) without backend schema changes, which aligns well with PostHog's flexible event property model.

The TODO comment for input validation is appropriate - semver validation can be added in a follow-up PR without blocking this functionality.

[greptile-apps]

_{3 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[tests-posthog]

Visual regression: Storybook UI snapshots updated

Changes: 1 snapshots (1 modified, 0 added, 0 deleted)

What this means:

• Snapshots have been automatically updated to match current rendering
• Next CI run will switch to CHECK mode to verify stability
• If snapshots change again, CHECK mode will fail (indicates flapping)

Next steps:

• Review the changes to ensure they're intentional
• Approve if changes match your expectations
• If unexpected, investigate component rendering

Review snapshot changes →