[camara-release-automation]

Release Review: r2.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
qos-booking-and-assignment	0.2.0-rc.2	rc	0.2.0-rc.1
qos-booking	0.2.0-rc.2	rc	0.2.0-rc.1

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 r2.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: r2.2-ae1884c

[camara-validation]

CAMARA Validation — PASS

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

View full results

[hdamker]

Pre-check from the Release Management side, ahead of the formal review. CAMARA Validation passes on the snapshot (one acceptable hint). The content findings from the manual checks are recorded as issues under the collector #161, grouped per API in #162 (qos-booking) and #163 (qos-booking-and-assignment). None of them can be fixed on the release-review branch.

qos-booking: the findings in #162 are small and self-contained: a missing mandatory response on the notification callback, a missing 422 code, test gaps, and wording. They are doable in the remaining time, either on main before a new snapshot of r2.2, or in a further release candidate before the public release. From my side nothing in #162 blocks publishing rc.2 as is, if the team prefers to collect the fixes for the next step.

qos-booking-and-assignment: the findings in #163 are of a different kind. Several of them are contradictions within the API definition about observable behaviour (reachability of terminated bookings, the state during an asynchronous deletion, the sink on assign and release, the semantics of the 201 responses), and each needs a design decision before it can be fixed consistently across API definition, tests and description. Resolving them well in the time left until the Sync26 M4 deadline for public releases looks challenging to me, and rushing them would risk another round of corrections after the public release. One option the team may want to consider, which has not been discussed in CQM yet: publish only qos-booking from this repository in Sync26, and continue qos-booking-and-assignment as an independent API in its own repository with its own release cadence. That would decouple the readiness of the two APIs without holding either back. I am raising this as a question for the team, not as a request; if the team wants to go that way, I can help with the repository setup.

CHANGELOG (secondary for now): the qos-booking-and-assignment sections are still at N/A, although the comparison with rc.1 contains breaking changes (renamed status and device-count fields, removed response codes, renamed event type). The qos-booking entries currently list PR titles; the new application server address patterns and the new 422 code should be listed as breaking changes. Both can be completed on this branch once the way forward is decided.