[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.0s
✅ API	spectral	1		0	1.44s
✅ GHERKIN	gherkin-lint	1		0	0.34s
✅ REPOSITORY	git_diff	yes		no	0.0s
✅ REPOSITORY	secretlint	yes		no	0.58s
✅ YAML	yamllint	1		0	0.36s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[GillesInnov35]

@hdamker-bot

repository:
meta_release: Fall25

could you tell me what the concerned meta-release. Is it the current one or for example spring26 even if no new release has been planed ?

Thanks
Gilles

[hdamker]

@hdamker-bot

repository: meta_release: Fall25

could you tell me what the concerned meta-release. Is it the current one or for example spring26 even if no new release has been planed ?

Thanks Gilles

@GillesInnov35 next reachable meta-release is Sync26 (aka Fall26). Spring26 is mainly for Commonalities and ICM.

[GillesInnov35]

thanks @hdamker-bot , yes I know that spring26 concerns only Commonalities and ICM. My question was not clear, sorry. It concerns the sentence # How this repository participates in CAMARA releases
My question is: as this API has not been concerned by the next meta-release spring26, should we write in the block
repository:
meta_release: Fall26 or let meta_release: Fall25

[hdamker]

thanks @hdamker-bot , yes I know that spring26 concerns only Commonalities and ICM. My question was not clear, sorry. It concerns the sentence # How this repository participates in CAMARA releases My question is: as this API has not been concerned by the next meta-release spring26, should we write in the block repository: meta_release: Fall26 or let meta_release: Fall25

If the plan of the team is to participate with their next public release in Sync(Fall)26 (which I hope), change it to Sync26. If you want to do a release already earlier, change the release track to independent (an initial API can release at any time if needed).

[GillesInnov35]

thanks, that's clear