Skip to content

[bulk] Add release-plan.yaml (2026-02-23-001)#35

Merged
gmuratk merged 2 commits intomainfrom
bulk/release-plan-rollout-22305485219
Apr 14, 2026
Merged

[bulk] Add release-plan.yaml (2026-02-23-001)#35
gmuratk merged 2 commits intomainfrom
bulk/release-plan-rollout-22305485219

Conversation

@hdamker-bot
Copy link
Copy Markdown
Contributor

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

@hdamker-bot hdamker-bot added the automated Automated bulk operations from project-administration label Feb 23, 2026
@github-actions
Copy link
Copy Markdown

github-actions bot commented Feb 23, 2026

🦙 MegaLinter status: ✅ SUCCESS

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

See detailed report in MegaLinter reports

MegaLinter is graciously provided by OX Security

@hdamker
Copy link
Copy Markdown
Contributor

hdamker commented Apr 2, 2026

Gentle reminder: this PR adds the release-plan.yaml configuration file as part of the release automation onboarding for CAMARA repositories (see ReleaseManagement#379). The file is purely additive and does not change any existing code or API definitions. A codeowner approval is needed to merge it. cc @gmuratk @lbertz02

@gmuratk
Copy link
Copy Markdown
Contributor

gmuratk commented Apr 2, 2026

Thanks for the reminder @hdamker ,
In the last CRR call on March 31, 2026, we discussed this PR and agreed to go with Option B and change the api-name. Action was taken to propose options prior to next meeting and update the release-plan.yaml before merging. This should take too long for us to decide, and merge the updated file.

@hdamker
Copy link
Copy Markdown
Contributor

hdamker commented Apr 13, 2026

This should take too long for us to decide, and merge the updated file.

@gmuratk Any updates?

@gmuratk
Copy link
Copy Markdown
Contributor

gmuratk commented Apr 13, 2026

@hdamker, We have our next meeting scheduled for tomorrow April 14, 2026. During or immediately following that we will make the update and merge.

@gmuratk gmuratk merged commit 9135ae9 into main Apr 14, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automated Automated bulk operations from project-administration

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants