Release r1.2 with click-to-dial v0.1.0-rc.1

[YadingFang]

What type of PR is this?

• subproject management

What this PR does / why we need it:

This PR contains release-preparation only changes for v0.1.0-alpha.2:

• Prepare/update CHANGELOG.md for the v0.1.0-alpha.2 release.
• Update the API Readiness Checklist for v0.1.0-alpha.2 (including minor formatting/newline fix).
• Update version fields from wip to v0.1.0-alpha.2 and adjust server/resource URLs where applicable.

This PR was created as a clean, reviewable replacement for the previous release PR #61, following Release Management guidance to avoid mixing CHANGELOG updates with substantial API/spec changes.

Special notes for reviewers:

• Supersedes: release: v0.1.0-alpha.2 — align /calls OpenAPI, CloudEvent schema, sinkCredential, examples, docs & tests #61 (the earlier release PR that included substantial spec changes).
• Substantial spec changes have been moved to separate PR(s) against main:
  • PR Add callback definition for call status change events #64 : Callbacks / sink event delivery documentation (Fixes Add OpenAPI callbacks for sink-based status change events #62)
  • PR docs(api): align /calls with OpenAPI  #63 : /calls documentation alignment (CloudEvents example, 422 business errors, call-flow diagram) (if split as a separate PR)
• This PR intentionally contains only release artifacts (CHANGELOG / Readiness Checklist / version & URL updates) to keep RM review lightweight.

[XunliYang]

LGTM

[YadingFang]

Note on PR history: This PR was temporarily auto-closed when the head branch was renamed (GitHub treats it as the branch being deleted). The original branch has been restored and the PR is now re-opened.

[YadingFang]

This PR has been converted from v0.1.0-alpha.2 to v0.1.0-rc.1, and we will use it as the M3 release. All version references have been updated consistently across the OpenAPI definition, docs, tests, changelog, and readiness checklist.

[tanjadegroot]

Looks good ! Almost there.

Some small comments which you can include while waiting for the Spring26 Commonalities and ICM Release PR (ICM is available).

For Commonalities, please see here for API impacts: https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/518225924/Analysis+of+Commonalities+0.7.0-rc.1

a few of them concern your API so need to be addressed for alignment with the Spring26 meta-release.
This alignment also implies updating the readiness checklist to point to the release 4.1 of both Commonalities and ICM.

Suggest to

• put the Release PR in draft,
• do updates on main
• synch Release PR when done
• reopen Release PR

[tanjadegroot]

Suggested change

	| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r3.3](https://github.com/camaraproject/Commonalities/releases/tag/r3.3) |
	| 2 | Design guidelines from Commonalities applied | O | M | M | M | Y | [r3.3](https://github.com/camaraproject/Commonalities/releases/tag/r3.4) |

[tanjadegroot]

Note: There was a Commonalities maintenance release on documentation, but not impact on the API definition

[tanjadegroot]

Release notes should not point to main (which is always in version "wip".

[tanjadegroot]

I would recommend not to duplicate release information in the API documentation as it is captured in the CHANGELOG.md and the README.md and will be handled automatically in the future.

Most API documentation should be in the API yaml file which should be self sufficient.

Additional info like the curl commands can be here to be part the release. Other information is up to you.

[tanjadegroot]

I noticed the use of the "subject" property in the CloudEvent structure (line 558) which is not supported by CAMARA. as the same information is already in the "data" property of the event, it can simply be removed.

[tanjadegroot]

A fix is needed on all three feature files.
Also they do not cover all error cases today (see comment)

[tanjadegroot]

1. The resource URL is missing from the background section. E.g. add after line 10:

And the resource "/click-to-dial/v0.1rc1/calls"

2. As x-correlator parameter is part of teh API, in the background section add!

And the header "x-correlator" complies with the schema at "#/components/schemas/XCorrelator"

Same comments on the other 2 feature files, but with resource adapted to .../{callId} and .../{callId}/recording respectively

[tanjadegroot]

The different error codes are not covered by test scenarios which would be useful for API consumers. However, you can address this also in a later version. But would recommmend to set item 8 (Enhanced test cases) = in the API readiness checklist to "N" at this point.

[tanjadegroot]

The README.md was not part of the review, but there are some changes to be made:

• line 18: change "customer " to "API consumer"
• the following functionalities should be mentiond as well:
  • the API allows to terminate a call
  • the API allows to download/retrieve the recording of the call (if available)

[tanjadegroot]

Last but not least the API documentation (README, yamls, etc.) has information about an application that would use the API, rather then about the API, e.g.

• the introduction part in the click-to-dial.yaml should really be removed as not about the API. and it refers to a feature that is not provided by the API (number masking), nor does the API manages "pools of minute". The could kept for future releases. For now I would remove this introduction section.
• the README refers to "web-based communication". but the consuming application may or may not be web based.
• there is references to buttons, display, and clicking, etc. which is not part of the API. (Actually one could consider renaming the API to "voice-call" API.)

Then there are error codes about information that does not seem to be covered/used by the API: INSUFFICIENT_BALANCE and RESTRICTED_DESTINATION. These probably should be removed for now and added in a later version of the API.

[YadingFang]

Thanks @tanjadegroot for the thorough and detailed review — very helpful.
Based on your suggestions, I will follow this workflow:

1. Convert this release PR to Draft
2. Create separate PRs against main to address the substantive changes (see below)
3. Sync this release branch after the main PRs are merged
4. Re-open this release PR for final RM review

Planned PRs against main:

PR-A: Test definitions

• Add resource URLs to all .feature test files
• Add x-correlator header usage/validation in the Background sections, referencing #/components/schemas/XCorrelator

PR-B: OAS alignment

• Add notificationsBearerAuth security scheme (required for subscription APIs)
• Remove the CloudEvent subject property (not supported by CAMARA; info is already in data)
• Revise/remove the Introduction section where it contains application-level descriptions not provided by the API
• Review the current list of error codes (e.g., INSUFFICIENT_BALANCE, RESTRICTED_DESTINATION) and remove/defer any that are not applicable for this version

PR-C: README cleanup

• Use "API consumer" terminology (instead of "customer")
• Ensure the README reflects supported API capabilities (e.g., terminate call / retrieve recording)
• Remove application-level descriptions (web-based UI/buttons/clicking, etc.)

PR-D: Commonalities/ICM alignment (pending final Spring26 baseline)

• Review/apply relevant impacts from the Commonalities 0.7.0-rc.1 analysis
• Update readiness checklist references accordingly (Commonalities/ICM r4.1 once finalized)

Updates in this release PR after syncing:

• Update the API Readiness Checklist references (Commonalities/ICM r4.1 once finalized)
• Set item 8 (Enhanced test cases) to "N" in the Readiness Checklist as suggested
  I'll respond to each specific comment as I address it and will link the corresponding main PR(s).