Monitor release-plan.yaml rollout to all repositories

[hdamker]

Problem description

All development workstreams for Phase 2 mass rollout are complete:

• Campaign implementation: project-administration#103
• Validation workflow: tooling#48

These PRs need to be merged and the campaign executed to complete the rollout of release-plan.yaml to all ~61 CAMARA API repositories.

Timing context

• Spring26: 6 API repositories participating
• Fall26 M0: Approaching soon - establishes release planning baseline for all repos

Possible evolution

Execute the rollout in the following sequence:

1. Merge PRs

• Merge tooling#48 (validation workflow)
• Merge project-administration#103 (campaign)

2. Update tooling tag

• Decision: Keep v0 or create v1?
• Move/create tag to include new validation infrastructure

3. Regression testing

• Verify existing workflows still work after tooling merge
• Test validation on sample repos
• Verify campaign dry-run still produces expected output

4. Execute campaign

• Run campaign in plan mode for final review
• Execute apply mode for all repositories
• Monitor PR creation across repos
• Track PR merge progress

5. Post-rollout

• Communication to API maintainers about new workflow
• Close related issues

Wiki tracker replacement

Note: Full replacement of wiki-based release trackers requires the Release Progress Tracker implementation (project-administration#108). This rollout establishes the data foundation (release-plan.yaml in all repos) that the tracker will consume.

Additional context

• Parent issue: Mass Rollout of release-plan.yaml to replace Wiki Trackers within January #342 (Mass Rollout)
• Related: tooling#49 (validation issue)
• Related: project-administration#99 (campaign issue)
• Dependency for wiki replacement: project-administration#108

Success criteria

• All ~61 API repositories have release-plan.yaml via merged PRs
• Validation workflow active on all repositories
• Data foundation ready for Release Progress Tracker

[tanjadegroot]

deploy release-plan.yaml to 6 Spring26 API so that release management can check the validity wrt tracker

[hdamker]

deploy release-plan.yaml to 6 Spring26 API so that release management can check the validity wrt tracker

As discussed within ReleaseManagement call on 2026-02-10, we will do it the opposite way: roll-out of release-plan.yaml to all API repositories (in waves), except the ones which declared to participate in Spring26 (to avoid to disturb the current release process).

[hdamker]

Status update:

• final fixes to the campaign workflow done in Fix release-plan rollout campaign for production use project-administration#136 and Fix campaign aggregate for single-artifact download layout project-administration#137
• As final tests see and review the created PRs in QualityOnDemand and ConsentManagement

[hdamker]

"Run campaign in plan mode for final review" (https://github.com/camaraproject/project-administration/actions/runs/22103521226):

• Spring26 candidates excluded: SessionInsights, HighThroughputElasticNetworks, IoTSIMFraudPrevention, NetworkInsights, ClickToDial, NetworkSliceBooking
• Archiving in progress repositories to be excluded: HomeDevicesQoD, SiteToCloudVPN, ShortMessageService
• Spring25 repositories (splitter) to be excluded: DeviceStatus, KnowYourCustomer

For all other repositories the workflow created valid release-plan.yaml files.

[tanjadegroot]

Comments on the bulk PR (sorry, there are quite a lot) - please use as you see fit

• in What is this: ... declares your release intentions for this repository and its APIs.
• shorten (and lower case) "Automated Release Progress Tracker (replacing wiki API tables)" to "Automated release tracking (replacing manual API Release Tracker pages on wiki)"
• in the note, change "... for the planned release automation. This does not yet enable the automated release workflow -- onboarding will follow separately." -> "for the release automation process which will be enabled shortly."
• in the Pre-populated data section, change "This file was generated from your latest release data ..." to "The release-plan.yaml file is generated from your current release data ..."
• remove line: "You only need to change target_release_tag when you actively plan your next release." as it is explained later.
• move the line with the hand pointer into the section below it.
• change "What to do now" -> "What to do next"
• Option A: change "... (recommended if no immediate release planned)" to "** ... (if no release planned yet)**"
• bullet 3: remove "-- the file will be updated when you plan your next release"
• Option B.1: add the possible release types "(e.g. pre-release-alpha or pre-release-rc)"

Specific to ConsentManagement: camaraproject/ConsentManagement#12

• Option A: "if you don't have an API name defined yet" - change to add "... name or yaml" ?
• align the What is this sections to be the same.
• there is reference to a place holder, but I do not see the placeholder in the release-plan.yaml which contains "consent-management". This should be described as an optional step, before A and B. (it is now there twice, in A and in B) e.g. "If the file contains a placeholder-entry -- replace it with the API name once available (later, when planning a release)". Options A and B should still be about if a release is planned or not.
• API status table could be in both PR descriptions

[hdamker]

@tanjadegroot thanks for the review. I took the opportunity to add some further improvements as well. The result is in camaraproject/project-administration#139 - please use the PR also for your final comments and/or approval.

The two test PR descriptions in QualityOnDemand and ConsentManagement are updated in place to make the new texts readable (the extension .mustache won't be rendered by GitHub).

BTW: The confusion about the missing placeholder entry was produced by my manual commit after the PR, in which I already replaced the placeholder. All repositories without a release will get the placeholder-entry as API name in the pre-provided API entry.

Replies to your comments in details (AI generated, but based on my proposals and review):

in What is this: ... declares your release intentions for this repository and its APIs.

Applied in both templates (“declares your release plan … and its APIs”). I used “plan” instead of “intentions” because it’s more concrete/operational. If you prefer the exact word “intentions”, it’s a safe swap.

shorten (and lower case) "Automated Release Progress Tracker (replacing wiki API tables)" to "Automated release tracking (replacing manual API Release Tracker pages on wiki)"

Applied verbatim in the TL;DR and repeated once in “What is this?” for reinforcement.

in the note, change "... for the planned release automation. This does not yet enable the automated release workflow -- onboarding will follow separately." -> "for the release automation process which will be enabled shortly."

I did not keep “enabled shortly” in the PR version because it invites timeline questions and can age badly. The note now keeps the key boundary: prerequisite + onboarding separate.

in the Pre-populated data section, change "This file was generated from your latest release data ..." to "The release-plan.yaml file is generated from your current release data ..."

Applied in the “with releases” template: “generated from your current release data …”.

remove line: "You only need to change target_release_tag when you actively plan your next release." as it is explained later.

Applied. That line is removed; guidance is contained within Option B.

move the line with the hand pointer into the section below it.

Applied. The “Please review and adjust …” line sits under “Pre-populated data”, after contacts are mentioned.

change "What to do now" -> "What to do next"

Applied in both templates.

Option A: change "... (recommended if no immediate release planned)" to "** ... (if no release planned yet)**"

Applied in both templates.

bullet 3: remove "-- the file will be updated when you plan your next release"

Applied. That phrasing is gone; we avoid repeating “you can change later” multiple times.

Option B.1: add the possible release types "(e.g. pre-release-alpha or pre-release-rc)"

Applied. Option B step 1 includes examples. Also added the full enum list in the collapsed <details> table.

Option A: "if you don't have an API name defined yet" - change to add "... name or yaml" ?

I didn’t add “or yaml” because it’s ambiguous. Instead, the no-releases template now frames it via the placeholder rule: you may keep the placeholder while target_api_status: draft. If you want this explicitly, better wording would be “API name or API definition file”.

align the What is this sections to be the same.

Applied. The “What is this?” section text is now aligned across both templates.

there is reference to a place holder, but I do not see the placeholder in the release-plan.yaml which contains "consent-management". This should be described as an optional step, before A and B. (it is now there twice, in A and in B) e.g. "If the file contains a placeholder-entry -- replace it with the API name once available (later, when planning a release)". Options A and B should still be about if a release is planned or not.

Applied, with one refinement: placeholder handling is now its own section before Options A/B, and Options A/B are purely “release planned yet or not”. Also clarified the nuance you added later: placeholder can remain while draft, but must be replaced before planning a release or raising status above draft.

API status table could be in both PR descriptions

Applied. Both templates include the table, but inside <details> to keep the PR body skimmable. I also added target_release_type meanings there for completeness.

[hdamker]

Updated status:

• Replacement of Fall26 -> Sync26 in release-plan.yaml template done together with Add release automation onboarding campaign and admin tooling project-administration#134

• Dry-run across 63 showed

  • that DeviceStatus and KnowYourCustomer won't get the release-plan.yaml -- which is correct as they were used only until Spring25. The APIs were released in Fall25 in their own repository
  • That 60 repositories would receive the PR with release-plan.yaml
  • That 1 repository with an existing PR would be skipped (PR now closed, so ConsentManagement will receive it as well)

• Apply run done for four repositories which volunteered to be early adopters of Release Automation: ConsentInfo, SessionInsights, DeviceMediaStreamingRate, QualityOnDemand. Generated PRs:

  • [bulk] Add release-plan.yaml (2026-02-22-001) ConsentInfo#47
  • [bulk] Add release-plan.yaml (2026-02-22-001) DeviceMediaStreamingRate#21
  • [bulk] Add release-plan.yaml (2026-02-22-001) QualityOnDemand#531
  • [bulk] Add release-plan.yaml (2026-02-22-001) SessionInsights#65

Looking all good ... ready for the roll-out.