[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.