Release Review: DedicatedNetworks r2.2 (rc Sync26)

[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
dedicated-network-accesses	0.2.0-rc.1	rc	0.1.0
dedicated-network-profiles	0.2.0-rc.1	rc	0.1.0
dedicated-network	0.2.0-rc.1	rc	0.1.0
dedicated-network-areas	0.1.0-rc.1	rc	N/A

Dependencies: Commonalities r4.3, 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

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-9521675

[camara-validation]

CAMARA Validation — PASS

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

View full results

[hdamker]

Release Management review — CHANGELOG notes

Thanks for the CHANGELOG rework since the earlier snapshot — the breaking changes are now documented per API, which was the open point from #128. Three smaller things below.

Not a change request — if the snapshot is discarded over the test-definition finding in my other comment, the CHANGELOG is regenerated. Recording these for whichever snapshot goes forward.

• New error code when network in wrong state #81 is listed under dedicated-network → Added, but it changed only dedicated-network-accesses.yaml. dedicated-network.yaml defines no 409 and no INCOMPATIBLE_STATE. The entry is correct under dedicated-network-accesses, where it also appears.

• Six breaking changes are not repeated in their normal update section, which lifecycle step 4 asks for: Accesses Support operations to manage access to dedicated network for multiple devices at a time #98 and Update pagination to align with commonalities #122, Profiles Format profile id as UUID #83 and Add pagination for network profiles #125, Networks Areas API proposal #87 and Format profile id as UUID #83.

• fix: remove three-legged access token note from createAccess operation #140 is unrecorded and belongs with Release Management review corrections #136 as one entry. Both removed the same three-legged-token requirement — Release Management review corrections #136 from info.description, fix: remove three-legged access token note from createAccess operation #140 from the createAccess operation description. Release Management review corrections #136's remaining content is not API-consumer-relevant. Suggested single entry:

  * Removed the requirement that the `device` identifier provided with a three-legged access token must match the token subject by @tlohmar in https://github.com/camaraproject/DedicatedNetworks/pull/136 and @jimfengjinhua in https://github.com/camaraproject/DedicatedNetworks/pull/140
  

Checked and correct: comparison targets per API, the Full Changelog base (r1.2 is the last public release), the Commonalities 0.8.0 / ICM 0.5.0 statement, and the README version bump.

Minor, no action: the generator emits all five update sections as * N/A, and Removed (all four APIs), Added (Profiles) and Breaking changes (Areas) were deleted instead of left at N/A. For a new API such as Areas, Breaking changes: N/A records "none expected" more clearly than an absent section.

[hdamker]

Release Management review — issues and release decision

Thanks @tlohmar and @jimfengjinhua for turning the previous round's findings around so quickly. Both fixes verified on this snapshot: #140 removed the three-legged token requirement from the createAccess operation description as well as from info.description, which closes #130 properly, and #141 resolved the x-correlator gaps behind #131. #132 and #133 remain correctly fixed.

New issues from this review:

• [Accesses, Areas] Test definitions send requests naming operationIds that do not exist in the API definitions #143 — test definitions send requests naming operationIds that do not exist in the API definitions (Accesses and Areas)
• [Accesses API] 422 MISSING_IDENTIFIER condition in info.description contradicts the error code definition #144 — 422 MISSING_IDENTIFIER condition in the Accesses info.description contradicts the code's own definition, and the surrounding section no longer covers the three-legged case after fix: remove three-legged access token note from createAccess operation #140
• maxItems bounds are set at int64 range and inconsistent across the four APIs #145 — maxItems bounds set at int64 range rather than a testable int32 value, and inconsistent across the four APIs

Open issues from the earlier review rounds: #129, #134, #138. I have added the missing error-case coverage to #138 rather than opening a separate issue for it.

On the release decision. I am not approving yet, and I am not requesting changes either — the call belongs with the Sub Project.

#143 is the one I would not carry into an rc. Test Cases (basic) is a mandatory asset at rc status, and the Testing Guidelines define the request step as naming the operationId from the spec, because that is what identifies the method and path. As written, 19 of the 26 scenarios in this release cannot be bound to an operation: all 8 in dedicated-network-accesses.feature and all 11 in dedicated-network-areas.feature. The other two feature files are correct.

To be clear about where this comes from: it is not a regression from the review rounds. The Accesses mismatches are already in the released r2.1 feature file, the Areas file has had them since it was added, and the earlier rounds — mine included — did not catch them.

The fix is additive and cannot be made on a snapshot branch, so acting on it means /discard-snapshot, fix on main, and a fresh snapshot. The alternative is to release r2.2 with the test definitions as they are and fix them for the next release. Happy to go with whatever the Sub Project decides.