Proposal: Mass Rollout of release-plan.yaml to replace Wiki Trackers within January

[hdamker]

Problem description
The initial strategy for introducing the automated release workflow focused on an "early adopter" phase (targeting ~20 repositories). However, this approach creates a prolonged transition period where two parallel systems must be maintained: the manual wiki-based release tracker tables and the new release-plan.yaml.

This duality causes several issues:

• Double Maintenance: Release managers and maintainers must track status in two places.
• Confusion: It is unclear which system is the single source of truth.
• Delayed Benefits: The majority of repositories see no immediate benefit from the new tooling.
• Documentation Complexity: Guidelines must explain two different processes simultaneously for months.

Possible evolution
Adopt a Mass Rollout Strategy to introduce release-plan.yaml to all ~61 active repositories by January 15, 2026.

This approach involves:

1. Automated Campaign: Using project-administration tooling to bulk-create release-plan.yaml PRs for all repositories based on existing data.
2. Immediate Replacement: Deprecating the manual wiki API tables and replacing them with the automated "Release Progress Tracker" (powered by the new YAML files) immediately after the rollout.
3. Minimal Initial Validation: Focusing initial checks on schema compliance and presence, rather than strict logical enforcement (which comes in later phases).

Alternative solution

Continue with the "Early Adopter" (phased) approach. This would delay full adoption until Late 2026, requiring the manual wiki trackers to be maintained in parallel for another 6-9 months.

Additional context

This decision acts as a "Quick Win" by designating release-plan.yaml as the single source of truth for release planning immediately. It establishes the necessary data foundation for the advanced validation and automation features planned for Spring26 and Fall26, without the burden of legacy maintenance.

PR #338 is updated accordingly and contains more details about this roll-out. PR #339 contains the proposed schema for release-plan.yaml

[ChinaUnicomXiaoDongrui]

@hdamker Hello, this idea seems quite good. Operating simultaneously on the wiki page and github can indeed be very confusing. I understand that in the future, all the release operations will be done on github. Each repository will create a release-plan.yaml file. We just need to update the content in this file to complete the application for version release. I don't know if my understanding is accurate. I hope to get your reply, thanks

[hdamker]

@ChinaUnicomXiaoDongrui your understanding is correct, you can read about the complete concept in CAMARA-Release-Workflow-and-Metadata-Concept.md or in the short presentation from the All-hands Call on last Thursday.

But up to now there is nothing to do for you, the changes will come via automated PR into your repositories during January.

[ChinaUnicomXiaoDongrui]

@hdamker ok thanks