Release/0.1.0 alpha.2

[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.

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.0s
✅ API	spectral	1		0	1.69s
✅ GHERKIN	gherkin-lint	3		0	0.99s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.72s
✅ YAML	yamllint	1		0	0.47s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[XunliYang]

LGTM

[YadingFang]

@hdamker
I’d appreciate some guidance on the next step regarding the release process.

We currently have an alpha PR under review, but with the M3 deadline (Jan 31) approaching, I want to make sure we follow the correct path for Spring26.

Given the timing, should we:

wait for the alpha PR to complete review before submitting an RC, or

go ahead and open an RC PR in parallel to avoid missing the Spring26 window?

Thanks in advance for your advice.

[hdamker]

@hdamker I’d appreciate some guidance on the next step regarding the release process.

We currently have an alpha PR under review, but with the M3 deadline (Jan 31) approaching, I want to make sure we follow the correct path for Spring26.

Given the timing, should we:

wait for the alpha PR to complete review before submitting an RC, or

go ahead and open an RC PR in parallel to avoid missing the Spring26 window?

Thanks in advance for your advice.

@YadingFang

Sorry, it seems we missed in Release Management this release PR. I will create now a release review issue for it in the ReleaseManagement repository.

My recommendation is to change this release PR (for r1.2) from -alpha.2 to -rc.1 (replacing it in all occurrences). It is not necessary to create the release with alpha.2 before.

Please be aware that you need to check if one of the changes of the Commonalities 0.7.0-rc.1 will be relevant for you and you need to adapt these changes. The release r4.1 of Commonalities is currently in preparation and you can find already some additional document in the wiki here.

cc: @tanjadegroot