Release Review: PredictiveConnectivityData r2.1 (rc Sync26)

[camara-release-automation]

Release Review: r2.1 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
predictive-connectivity-data	0.2.0-rc.1	rc	0.1.0

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.1-ecd8a33

[camara-validation]

CAMARA Validation — PASS (with warnings)

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

View full results

Warnings MUST be documented in one or more issues before this release — see the Codeowner Actions in the PR description.

[albertoramosmonagas]

Issue created: #65 regarding to the point "Document deferred validation warnings (and hints)". Is there anything left to do before I can click “The release is ready for Release Management review”? WDYT @eric-murray?

[eric-murray]

Issue created: #65 regarding to the point "Document deferred validation warnings (and hints)". Is there anything left to do before I can click “The release is ready for Release Management review”? WDYT @eric-murray?

Hi @albertoramosmonagas

I created PR #66 to use the cloud events format for the notifications, which fixes the validation warnings. I left it as a draft for now, but if you are happy with it, it could be merged for the release candidate. You would need to discard this snapshot and create a new one.

I will also need update the test cases.

[albertoramosmonagas]

Issue created: #65 regarding to the point "Document deferred validation warnings (and hints)". Is there anything left to do before I can click “The release is ready for Release Management review”? WDYT @eric-murray?

Hi @albertoramosmonagas

I created PR #66 to use the cloud events format for the notifications, which fixes the validation warnings. I left it as a draft for now, but if you are happy with it, it could be merged for the release candidate. You would need to discard this snapshot and create a new one.

I will also need update the test cases.

Hi @eric-murray, thanks for preparing this and for keeping the PR as a draft.

Before merging it into the release candidate, I think we should distinguish between an event notification and an asynchronous response. In this API, the callback delivers the final result of a previously accepted request exactly once; it is not reporting an event that may occur independently or repeatedly.

This distinction is now being clarified in Commonalities PR #575, based on Issue #533. The proposed guidance explicitly states that asynchronous responses do not need to use the CAMARA CloudEvents model and should instead reuse the equivalent synchronous response model.

Therefore, the current linter warnings do not necessarily indicate that the API design is incorrect; the validation rules may not yet account for this distinction. The existing issue already documents the relevant P-015 and S-035 warnings for release purposes. Under the release-management guidelines, documented warnings and applicable hints are not blockers for the RC.

My proposal would be to keep PR #66 in draft, proceed with the current snapshot, and discuss after the release whether the API should remain aligned with the asynchronous-response guidance or deliberately adopt CloudEvents. This also avoids changing the contract and test cases immediately before the RC based solely on a potentially over-general validation rule.

WDYT?

CC: @PedroDiez