Release Review: SimSwap r4.2 (rc Sync26)

[camara-release-automation]

Release Review: r4.2 rc

This PR finalizes the reviewable release content for the active snapshot.

Edit and review this PR before merging it into the release snapshot. After Codeowner and Release Management approval, merging this PR creates the draft release.

Release contents

API	Version	Status	Comparison target
sim-swap-subscriptions	0.4.0-rc.2	rc	0.4.0-rc.1
sim-swap	2.2.0-rc.4	rc	2.2.0-rc.3

Dependencies: Commonalities r4.4, ICM r4.2

Codeowner Actions

Tick each box once done. Ticking the last box — "The release is ready for Release Management review" — starts the Release Management review.

• Update the CHANGELOG

  What to do:

  • Copy all API-consumer-relevant changes from the provided list into the appropriate Breaking changes / Added / Changed / Fixed / Removed sections for each API. List breaking changes both in Breaking changes and in their normal change category.
  • Do not copy administrative, tooling-only, or internal maintenance changes unless they affect API consumers.
  • For each API, fill the CHANGELOG against the stated comparison target, following the release-type rules at the top of the CHANGELOG.

• Document deferred validation warnings (and hints)

  What to do:

  • Check the CAMARA Validation comment on this PR for warnings and hints.
  • For each warning you do not fix, document it in an issue: include a copy of the validation summary line(s) and the reason the fix is deferred.
  • Document in the same way any validation hint that is applicable to the API and needs to be fixed later.
  • You may group several findings into one issue or split them across issues — either is fine.
  • List the documenting issue(s) in a comment on this PR.
  • Note: documenting deferred warnings is optional but recommended for alpha pre-releases, and mandatory for rc pre-releases and public releases.

• The release is ready for Release Management review

  Check that:

  • All mandatory release assets for the declared status(es) are present (see the table below "Required release assets per API status" by expanding the arrow);
  • API documentation and test cases are adequate for the target status.

  Tick this box to confirm readiness and to start the Release Management review.

Release Management Actions

The following actions and checks are done by a Release Management reviewer before approving the PR:

• Assign the Release Management reviewer(s) as assignee(s) of this PR
• CHANGELOG follows the release documentation rules
• Breaking changes are documented and version updates follow SemVer rules
• Mandatory release assets are present for each API according to its status
• All remaining validation warnings are documented in issues and the reasons for deferral are defensible
• Content findings needing a main PR are collected as sub-issues of one issue titled Release r4.2 review findings (see Recording review findings)

Required release assets per API status

Nr	Asset	alpha	rc	initial public	stable public
1	Release Plan	M	M	M	M
2	API Definition(s)	M	M	M	M
3	Commonalities compliance	O	M	M	M
4	API Documentation	M	M	M	M
5	User Stories	O	O	O	M
6	Test Cases (basic)	O	M	M	M
7	Test Cases (enhanced)	O	O	O	M
8	API Description	O	O	M	M

M = Mandatory, O = Optional — Full documentation

Valid next actions for codeowners

• Merge this PR when all Codeowner Actions and Release Management Actions are complete and the required approvals are present — creates the draft release
• Use /discard-snapshot <reason> in the Release Issue to discard this snapshot, return to planned, and update content on main

---

Snapshot: r4.2-696080a

[camara-validation]

CAMARA Validation — PASS

0 errors, 0 warnings, 0 hints | Profile: standard

View full results

[hdamker]

Validation is clean, and the P-027 warnings from the discarded snapshot (#304) are fixed. A few CHANGELOG gaps against rc.1 remain. Most of them cancel out in the public release, which is compared with 0.3.0 / 2.1.0, so short entries are enough here:

1. Removed (both APIs): the error codes trimmed with the r4.4 error catalogue, as announced in the r4.1 CHANGELOG. For example:
   • sim-swap-subscriptions: "Error codes not applicable to this API: 400 OUT_OF_RANGE (GET /subscriptions), 403 INVALID_TOKEN_CONTEXT, 403 SUBSCRIPTION_MISMATCH, 404 IDENTIFIER_NOT_FOUND, 409 CONFLICT, 409 INCOMPATIBLE_STATE, 422 MULTIEVENT_*, 422 UNSUPPORTED_IDENTIFIER, 429 QUOTA_EXCEEDED"
   • sim-swap: "Error codes not applicable to this API: 404 NOT_FOUND, 429 QUOTA_EXCEEDED, 400 OUT_OF_RANGE (POST /retrieve-date)"
2. Breaking changes (sim-swap-subscriptions): phoneNumber is no longer required in the swapped event data. It is required in rc.1, so event receivers can no longer rely on it. Keep it under Fixed as well.
3. Changed (both APIs): the first entry is the PR title "Align Commonalities r4.4 to Sim Swap and Subscriptions", repeated in both API sections. It would be clearer to say what changed in each API, e.g. "Aligned with Commonalities r4.4 (0.9.0): error responses taken from the r4.4 error catalogue, mandatory info.description sections updated, by @albertoramosmonagas in #295".

[bigludo7]

Thanks @hdamker for the review & @albertoramosmonagas for the fixes. all suggestions applied.

[hdamker]

@bigludo7 @albertoramosmonagas: Thanks for applying the first round of review comments. Could be merged as is.

Two optional suggestions: the breaking-change entry now says that phoneNumber was already optional in 0.3.0, so it reads as a revert of an rc.1 change and not as a new restriction; and the entries no longer have the fix: prefix from the PR title.

Beyond that I have filed #308 with cosmetic changes to be applied with the next edits.

[bigludo7]

LGTM

[bigludo7]

@albertoramosmonagas What is your preference - Do we manage @hdamker #308 proposal within this RC (and discard) or we merge this one and craft a new RC?

[albertoramosmonagas]

@albertoramosmonagas What is your preference - Do we manage @hdamker #308 proposal within this RC (and discard) or we merge this one and craft a new RC?

As far as I'm concerned, and since we have time to do it now, we can tackle it, does that sound good to you? That way, we won't have to wait for the next cycle. The changelog has already been reviewed, so once we have the other issue done, all we'd have to do is add one more item to this changelog copy-and-paste

[bigludo7]

Yes work for me !