Next steps towards release r1.2 (v0.1.0-rc.1) #79
Description
The PR #65 got closed due to the renaming for the branch from release/0.1.0-alpha.2-clean to release-0.1.0-alpha.2-clean. As you have decided to go with the new automated release process and prepared the main branch accordingly, the PR is no longer needed (also #72 and #73 should be closed).
The next steps towards release r1.2 are
- Read and merge PR [bulk] Enable release automation process (2026-03-09-001) #80, it will
- add the Release Automation workflow
- delete the API readiness checklist which is no longer needed with the new process
- run once the Release Automation workflow as described in the PR description
- that will create the new - workflow owned - Release Issue in state "planned"
- work through the checklist in the Release Issue
- e.g. consider to address Missing Gherkin test definition for getCall operation #78 with a PR into main before you start the release process
- when ready post
/create-snapshotas a comment in the release issue- that will create the new Release Review PR
- edit the CHANGELOG-r1.md file in Release Review PR
- you can copy the content for Added/Changed/Fixed/Removed from https://github.com/camaraproject/ClickToDial/blob/release-0.1.0-alpha.2-clean/CHANGELOG.md
- get Codewoner and Release_reviewer approvals for the PR and merge it
- follow the further instructions in the Release Issue
Regarding your questions:
- Close PR Release r1.2 with click-to-dial v0.1.0-rc.1 #65 and merge the remaining release artifacts (CHANGELOG, Readiness Checklist) directly into main first?
Release r1.2 with click-to-dial v0.1.0-rc.1 #65 got already closed. Close Align with Spring26 Commonalities r4.1 / ICM r4.1 in CHANGELOG #72 and Update references to Commonalities and ICM to r4.1 #73 as well, don't merge them intomain.
- Or will the onboarding PR handle migrating PR Release r1.2 with click-to-dial v0.1.0-rc.1 #65's content?
You need to copy the prepared change descriptions into the Release Review PR created by the automation, see above.
@hdamker Thanks for the explanation! I'd like to go with Option 2.
Regarding the release branches you mentioned in your comment:
release/0.1.0-alpha.2-clean — currently used by PR #65
release/r1.2-v0.1.0-rc.1 — no longer needed (leftover from an earlier rename), can be deleted
release/0.1.0-alpha.2 — no longer needed, can be deletedWhat's been done so far:
- PR chore: reset test resource URLs to vwip on main (fixes #75) #77 addresses Reset API and test code version information in main branch to wip #75 — reset test resource URLs to vwip on main
- PR Update release track and dependencies in release-plan.yaml #74 (merged) — updated release-plan.yaml with meta_release: Spring26, release_track: meta-release, and dependencies set to r4.1
- PR Align with Spring26 Commonalities r4.1 / ICM r4.1 in CHANGELOG #72 / Update references to Commonalities and ICM to r4.1 #73 — CHANGELOG and Readiness Checklist updates targeting the release branch (currently blocked by the branch protection)
One question about Option 2: PR #65 contains release artifacts (CHANGELOG updates, API Readiness Checklist, version bumps) that are currently only on the release/0.1.0-alpha.2-clean branch. Since the automated release process creates the release branch from main, should I:
- Close PR Release r1.2 with click-to-dial v0.1.0-rc.1 #65 and merge the remaining release artifacts (CHANGELOG, Readiness Checklist) directly into main first?
- Or will the onboarding PR handle migrating PR Release r1.2 with click-to-dial v0.1.0-rc.1 #65's content?
Originally posted by @YadingFang in #65 (comment)