[bulk] Add release-plan.yaml (2026-02-23-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

The release-plan.yaml file is generated from your current release data and repository settings:

• Release tag: target_release_tag is set to r2.2 (detected from your current release)
• APIs: derived from your current release (r2.2)
• Contacts: from your CODEOWNERS file

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

What to do next

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

• The file reflects your current release state (r2.2, Fall25)
• target_release_type: none means "no release currently planned"
• Just merge

Option B: Update before merging (if planning your next release now)

1. Set target_release_type (e.g. pre-release-alpha or pre-release-rc)
2. Update target_release_tag for your next release:
   • New cycle: increment first number, reset second to 1 (e.g., r3.2 → r4.1)
   • Progression in same cycle: increment second number (e.g., r3.2 → r3.3)
3. Update target_api_version for any APIs being changed
4. Optionally add meta_release: Sync26 if participating in the meta-release

API status and release type meanings (for later)

target_api_status

Status	Meaning
draft	API work in progress / definition not ready
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	3		0	5.0s
✅ GHERKIN	gherkin-lint	11		0	3.65s
✅ REPOSITORY	git_diff	yes		no	0.02s
✅ REPOSITORY	secretlint	yes		no	0.92s
✅ YAML	yamllint	3		0	0.91s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[stroncoso]

Hi,

I need to properly digest the documentation prior to approve.
Our current status is:

• Published r2.2 as the bot covers at release-plan.yaml
• We are working on new features to launch r3x on the next Fall26 release (PRs open).

It is likely that we need to tweak the file, but I will review prior the documentation to get a better understanding of the implications.

Regards,

[stroncoso]

Hi @deepakjaiswal1 , @teikuran ,

As I did changes on the PR, it will be good that you approve the changes. The main point here, as explained on the last meeting, is to declare our intent to release the API updates referred at #137 . This file will trigger the CI process to be included on the meta-release.

Comments and questions are welcome.

Best regards,

[hdamker]

please use r4.1 for both already - we appreciate if APIs already adapt to the release candidates, so that the working groups get feedback.