[bulk] Add release-plan.yaml (2026-02-22-001)

[hdamker-bot]

Add release-plan.yaml for automated release tracking

TL;DR: This PR adds release-plan.yaml for automated release tracking (replacing manual API Release Tracker pages on wiki).

Note: Adding release-plan.yaml is a prerequisite for the upcoming release automation process.
This PR does not yet enable the automated release workflow; onboarding will follow separately.

What is this?

The release-plan.yaml file declares your release plan for this repository and its APIs. It enables:

• Automated release tracking (replacing manual API Release Tracker pages on wiki)
• CI validation of release readiness
• Automated release preparation (enabled during onboarding)

Pre-populated data

• Contacts: from your CODEOWNERS file
• APIs: an initial placeholder entry is provided (even if API definition files already exist)

👉 Please review and adjust if API-specific contacts differ from repository-wide codeowners.

Placeholder API entry (before your first release)

For repositories without prior releases, the generated release-plan.yaml contains a placeholder API entry.

• If you already know the final API name(s), please replace the placeholder now.
• If the API name is not decided yet (e.g. community discussion ongoing), you may keep the placeholder as long as target_api_status: draft.

👉 Before planning a release (by setting target_release_type to a non-none value, see table below) or changing the API status above draft, you must replace the placeholder with the final API name(s).

What to do next

Option A: Merge as-is (if no release planned yet)

• Keep target_release_type: none
• Keep APIs at target_api_status: draft
• You can update names and add additional API entries later (recommended as soon as API naming is settled)

Option B: Update before merging (if you already know your API name(s))

1. Replace placeholder-entry with your intended API name(s) (kebab-case, per Commonalities naming guidelines)
2. Keep target_api_status: draft unless you are ready to declare alpha or rc
3. Review main_contacts (pre-populated from CODEOWNERS)

When ready to release

1. Ensure API names in release-plan.yaml match your files in code/API_definitions/
2. Update target_api_status from draft to alpha or rc (depending on your release target)
3. Set target_release_type (e.g. pre-release-alpha)

API status and release type meanings

target_api_status

Status	Meaning
draft	API declared, definition file not required yet
alpha	API definition exists, ready for early feedback
rc	Release candidate, feature-complete
public	Public release

target_release_type

Value	When to use
none	No release currently planned
pre-release-alpha	Early, incomplete preview release for feedback
pre-release-rc	Release candidate publication
public-release	Public CAMARA release
maintenance-release	Patch/maintenance release in an existing cycle

Documentation

📖 Release Management Documentation
📖 The release-plan.yaml File
📖 Release Lifecycle
📖 API Versioning

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.01s
✅ API	spectral	1		0	1.48s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.62s
✅ YAML	yamllint	1		0	0.4s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[hdamker]

@maheshc01 thanks for volunteering to be an early adopter of the the Release Automation! The actual onboarding to Release Automation will follow, will take a few days still.

[hdamker]

@maheshc01 Thanks for volunteering to be one of the first repositories to use the new automated release process. To be able to onboard the repository, you need to approve and merge this PR. I propose that you merge it first unchanged, then the next PR as well, and after that update the release-plan.yaml with a small PR. The push will then trigger the workflow and create the Release Issue for the planned release.