Feedback Request: Bulk Campaign for Release Information Sync

[hdamker]

Overview

The bulk campaign infrastructure for automated Release Information section updates is now ready for use. This issue requests feedback from repository codeowners before proceeding with a full rollout.

What is This?

An automated workflow that synchronizes Release Information sections across CAMARA API repositories to ensure consistency and accuracy. The workflow:

• Updates README.md Release Information sections with latest public release data
• Harmonizes formatting and documentation links across all repositories
• Creates PRs for codeowner review before any changes are merged

With that it implements the agreed template as defined in camaraproject/ReleaseManagement#273

It is also the base for further automated project administration campaigns.

Test Campaign Results

Tested against 3 repositories:

• QoSBooking: PR #73 - Updated with latest release information
• QualityOnDemand: PR #509 - Demonstrates superseding of old PRs
• SimSwap: Error detected (missing section markers) - requires manual preparation

Features Validated

• PR title numbering with date and sequence
• Unique branch per run (no force-push)
• Superseding of outdated PRs with draft conversion
• Two-stage change detection (prevents duplicate PRs)
• Error handling (repositories without section markers reported)

Example PR Content

See QoSBooking PR #73 for an example of:

• Release Information section format
• Documentation links (YAML, ReDoc, Swagger)
• GitHub NOTE callout for compatibility warnings
• Delimiters for automated updates
• Instructions for codeowners

Feedback Requested

1. PR Format and Content

• Does the PR body provide sufficient context?
• Are the codeowner instructions clear?
• Is the content preservation warning adequate?

2. README.md Changes

• Is the new Release Information format as agreed and acceptable?
• Are the documentation links appropriate?
• Any concerns with the delimited section approach?

3. Repository Preparation

• SimSwap and PopulationDensityData repositories need to change the section title to "## Release Information"
• Proposal to create small PRs for that upfront of the roll-out

4. Rollout Strategy

Options:

1. Phased rollout: Define a list of repositories to update in a first wave (e.g. all Incubating API Repositories)
2. Full rollout: Prepare all repositories first, then run campaign across all 43

Which approach would you prefer?

5. Campaign Frequency

• One-time synchronization after each known public release?
• Scheduled periodic updates?
• Manual trigger only?

Note1: the workflow relies on data/releases-master.yaml which will be updated by another workflow (currently under test, needs some final improvements). The file currently contains the release data of 43 repositories, as of Fall25 meta-release.

Note2: the workflow cannot currently support updates during release creation (as the release is not yet available). That will be handled by separate workflows triggered within the repositories. As soon as release creation is automated, the workflow can be integrated into that process.

Next Steps

Based on feedback received:

1. Address any concerns with PR format or content
2. Coordinate SimSwap and other repository preparations
3. Finalize rollout strategy
4. Execute campaign
5. Monitor and iterate based on codeowner feedback

Technical Details

Workflow: campaign-release-info
Documentation: campaigns/release-info/docs
Test Runs: Plan mode | Apply mode | Idempotency

Timeline

Please provide feedback by 2025-11-04 (next ReleaseManagement call)

---

Note: All PRs created by this campaign require codeowner approval before merging. No automatic merges will occur.

[albertoramosmonagas]

Hi! I use the same format to give feedback:

1. PR Format and Content

• It could be useful to explain why this automation is being introduced and what problem it solves, for example, ensuring consistency of release data across repositories and reducing manual maintenance effort. That context would help codeowners understand the intent behind the campaign.
• The instructions to codeowners are clear on approval flow but not on the scope of review. It should explicitly say that they only need to check placement and delimiters, not the actual content (versions, tags, or release dates), as this information comes from data/releases-master.yaml. The review should focus on avoiding README conflicts rather than validating release data.

---

2. README.md Changes

• It might be valuable to include the maturity (Initial / Stable) and a reference to the corresponding meta-release. Since this campaign is meant to align with Release Management, those fields would reinforce traceability to Commonalities / ICM and the M3–M5 process.
• The README should explicitly mention that the documentation links are automatically generated from data/releases-master.yaml, so maintainers understand the source of truth and do not edit the section manually. While this is covered in the docs and issue, making it visible in the README itself would avoid confusion.
• UX detail: the PR Enable Release Info Sync full roll-out #73 adds an HTML comment after the START marker explaining that the section is maintained by project-administration. That’s helpful, but we recommend adding a visible text line such as:

  “This section is automatically synchronized by CAMARA project-administration.”
  This would prevent accidental edits by maintainers unaware of the automation.

---

3. Repository Preparation

• It should be clarified who creates the preparation PRs, the codeowner or the bot. Given the scope of this campaign, having the bot or project-administration open those PRs centrally would ensure consistency and avoid fragmented efforts.

---

4. Rollout Strategy

• The real operational risk is higher in stable repositories, not in sandbox ones. If something goes wrong (e.g., the bot overwrites manual content or inserts broken links), the impact is much greater on public, production-ready APIs. Therefore, a phased rollout makes sense — but in reverse order:
  • Phase 1: Incubating / Sandbox repos, to validate format and idempotency.
  • Phase 2: Stable repos, once the process has proven safe.

---

5. Campaign Frequency

• Running the sync after every public release is possible, but the meta-release cadence is already the natural synchronization point → Recommended frequency: twice per year, aligned with Spring and **Fall meta-releases, right after M4 closure when releases are validated.

• The rollout should avoid overlapping with release creation or freeze periods; the safest window is post-meta-release (M5), when README updates won’t interfere with active versions.

• For patches / hotfixes (e.g., rX.y+1 outside the meta-release), allow an optional manual trigger, restricted to project-administration, to avoid constant PR noise.

• Governance of responsibility should be explicit:

  • If project-administration initiates the push, it should announce the sync date.
  • Release Management WG and Backlog WG should be informed in advance, since the campaign affects public documentation links and visibility.