fix: update release PR native SDK version handling

[fadi-george]

One Line Summary

Fix the Create Release PR workflow so native Android and iOS SDK inputs update the version variables currently used by the SDK manifests.

Motivation

The Android Gradle file and iOS podspec now store native SDK versions in local variables, but the release PR workflow was still reading and replacing the previous inline dependency formats. This could leave release PRs with stale native SDK versions.

Scope

Updates .github/workflows/create-release-pr.yml to read and update oneSignalVersion in android/build.gradle and onesignal_xcframework_version in ios/onesignal_flutter.podspec.

Keeps the existing Package.swift iOS SDK update behavior unchanged.

Testing

• ReadLints on .github/workflows/create-release-pr.yml
• git diff --check -- .github/workflows/create-release-pr.yml
• Local sed simulations for the Android and iOS version-variable replacements

Affected code checklist

• CI / GitHub Actions
• Android runtime code
• iOS runtime code
• Dart API surface
• Documentation

Checklist

• Changes are scoped to the release PR workflow
• Version replacement commands are aligned with the current manifest formats

Made with Cursor

[nan-li]

@claude review

[claude]

LGTM — mechanical workflow fix that aligns sed patterns with the current version-variable formats in build.gradle and the podspec.

Extended reasoning...

Overview

This PR updates .github/workflows/create-release-pr.yml to fix the read/replace sed commands for the Android and iOS native SDK versions. The previous patterns targeted inline com.onesignal:OneSignal:<ver> and s.dependency 'OneSignalXCFramework', '<ver>' strings, but the manifests now define versions in local variables (def oneSignalVersion in android/build.gradle, onesignal_xcframework_version in ios/onesignal_flutter.podspec). The Package.swift update path is untouched.

Security risks

None. This is a CI workflow change that runs sed against repo-internal files. No new secrets are introduced, no external inputs are interpolated unsafely beyond what was already present, and no permissions changes are made.

Level of scrutiny

Low. The change is a small, scoped regex fix to a release-tooling workflow with no runtime impact. I verified the regexes against the current source files: android/build.gradle:10 is def oneSignalVersion = '5.9.3' (matches the anchored ^def oneSignalVersion = ['"]... read/replace pair), and ios/onesignal_flutter.podspec:5 is onesignal_xcframework_version = '5.5.2' (matches ^[[:space:]]*onesignal_xcframework_version = ['"]...). Both patterns correctly use -E extended regex with a character class for either quote style.

Other factors

The PR is single-file and ~4 lines of effective change. Worst case if the regex were wrong is a no-op sed (visible immediately when the release PR is opened and shows no diff), not a corrupted release. Bug hunting system returned no findings.