[SDK-489] release-2-2-2#865
Conversation
There was a problem hiding this comment.
Pull request overview
Release bump to version 2.2.2, updating version strings and adding changelog entries.
Changes:
- Bump package version from 2.2.1 to 2.2.2 in
package.jsonandsrc/itblBuildInfo.ts - Add 2.2.2 and 2.2.1 entries to
CHANGELOG.md
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/itblBuildInfo.ts | Update build info version to 2.2.2 |
| package.json | Update package version to 2.2.2 |
| CHANGELOG.md | Add release notes for 2.2.2 and 2.2.1 |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Coverage Impact This PR will not change total coverage. 🚦 See full report on Qlty Cloud »🛟 Help
|
sumeruchat
left a comment
There was a problem hiding this comment.
LGTM for the release — full clean smoke test passed end-to-end (root+example yarn install, bundle exec pod install, iOS xcodebuild BUILD SUCCEEDED, ./gradlew :app:assembleDebug BUILD SUCCESSFUL in ~1m 43s / 189 tasks, yarn build/typecheck/lint/test all green, npm pack --dry-run produces a clean 2.2.2 tarball). Version is consistent across package.json, src/itblBuildInfo.ts, and the podspec (which reads from package.json). Thanks for pinning baseline-browser-mapping to ^2.10.29 — appreciated.
Approving, but a few non-blocking cleanups worth doing before tagging/publishing:
1. CHANGELOG attribution (P2)
The current 2.2.2 section credits things that actually belong to PR #860 / the 0.79 line (baseline-browser-mapping added, Xcode 26.4 Podfile workaround — commit a7768d4 is from #860). And the new 2.2.1 section is tricky because tag 2.2.1 already exists at 642b6796 and its CHANGELOG didn't contain the RN 0.79 entry — so adding a new 2.2.1 section here would retroactively rewrite an already-published release.
Suggestion: drop the new 2.2.1 section entirely, and rewrite 2.2.2 to reflect what this release actually adds (it brings in both 0.80.3 and 0.81.6, not just 0.81):
## 2.2.2
### Updates
- Updated React Native example/dev compatibility through 0.80.3 and 0.81.6
- Pinned `baseline-browser-mapping` to `^2.10.29`
### Fixes
- Added temporary fix for Xcode 26.4 compatibility ([a7768d4](https://github.com/Iterable/react-native-sdk/commit/a7768d4)) in example app(Keep the Xcode 26.4 line under 2.2.2 only if the team intends 2.2.2 to be the first public release that contains all three upgrade PRs — i.e. if 2.2.1 was never actually published with those changes. If 2.2.1 already shipped that fix, drop it from 2.2.2.)
2. README version mapping (P2)
README.md version table at line ~123 still tops out at 2.2.0. After this PR, the podspec resolves to Iterable-iOS-SDK 6.6.7 (Android stays at 3.6.2). Please add a row:
| [2.2.2](https://www.npmjs.com/package/@iterable/react-native-sdk/v/2.2.2) | [3.6.2](https://github.com/Iterable/iterable-android-sdk/releases/tag/3.6.2) | [6.6.7](https://github.com/Iterable/swift-sdk/releases/tag/6.6.7) |(Worth a sanity check on whether a 2.2.1 row is also missing for consistency.)
3. Optional tarball cleanup (P3)
npm pack --dry-run for 2.2.2 includes test files in the published package — src/core/classes/Iterable.test.ts, lib/module/.../*.test.js, lib/typescript/.../*.test.d.ts. The files allowlist in package.json only excludes __tests__/__fixtures__/__mocks__, and .npmignore patterns aren't kicking in here.
If we want a tighter publish artifact, add "!**/*.test.*" (or similar) to package.json files. Not a blocker if this matches existing published behavior.
SemVer note (FYI, not a request)
PATCH is defensible since the public JS/native SDK API doesn't change and peerDeps stays *. That said, MINOR (2.3.0) would communicate the support-matrix expansion (0.79 → 0.80 → 0.81) more clearly to consumers. Up to you — happy with PATCH if that's the team's existing convention for RN-compat bumps.
Also: retracting my earlier Android rnc-cli concern
In my #862 review I flagged that clean Android builds failed because @react-native-community/cli@20.0.0's bin.js ships as 0644 and Yarn 3 node-modules creates a non-executable symlink → npx rnc-cli: Permission denied. On this branch from a clean install (example/node_modules wiped), bin.js lands as mode 755 and ./gradlew :app:assembleDebug completes cleanly. So either my earlier repro was a transient state issue (maybe leftover node_modules permissions from a previous toolchain), or Yarn 3 is restoring the bit correctly when nothing's pre-existing. Either way — not reproducing on this release branch, so this is no longer a concern for tagging 2.2.2.

🔹 JIRA Ticket(s) if any
✏️ Description