[TEST - DO NOT MERGE] Add release-plan.yaml (2026-01-17-001)

[hdamker-bot]

Add release-plan.yaml for automated release tracking

This PR introduces release-plan.yaml -- a metadata file that will replace manual wiki-based release tracking with automated tooling.

What is this?

The release-plan.yaml file declares your release intentions for this repository. It enables:

• Automated Release Progress Tracker (replacing wiki API tables)
• CI validation of release readiness
• Automated release branch creation (coming soon)

Pre-populated data

This file was generated from your latest release data and repository settings:

• Release tag: target_release_tag is set to r2.2 (your latest release)
• APIs: From your most recent release (r2.2)
• Contacts: From your CODEOWNERS file

You only need to change target_release_tag when you actively plan your next release.

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

What to do now

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

• The file is pre-populated with your current release state (r2.2, Fall25)
• target_release_type: none means "no release currently planned"
• Just merge -- the file will be updated when you plan your next release

Option B: Update before merging (if planning a release soon)

1. Set target_release_type to your intended release type
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: Fall26 if participating in the meta-release

Before your next release

Update this file with your release intentions:

repository:
  target_release_tag: rX.Y      # Your next release tag
  target_release_type: pre-release-alpha  # Or: pre-release-rc, public-release, maintenance-release

Documentation

📖 Full documentation (work in progress)
📖 Release Workflow and Metadata Specification
📖 API Versioning (in CAMARA API Design Guide)

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.01s
✅ API	spectral	3		0	4.89s
✅ GHERKIN	gherkin-lint	11		0	3.49s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.84s
✅ YAML	yamllint	3		0	0.96s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[stroncoso]

Hi @hdamker,

Thanks for the tool, seems great but I have some questions about it and what it does. Do you have more elaborated documentation about the bot itself and the autonomous process? I can't figure the procedure changes on the links provided.

Our intention is to participate into the Fall26 with the scope of #111 , changes are not ready yet. So, my I understand that we need to update the YAML file prior to merge.

In consequence, some practical questions arise:

• Should we update and merge this MR already? Even if the changes are not ready yet?
• Does this replace the release issue? Should we link it to the release-plan.yaml somehow?
• Should we need to keep updating the documentation/API_documentation folder and its markdown files?

Thanks in advance!
Best regards,

[hdamker]

Hi @stroncoso

Thanks for the tool, seems great but I have some questions about it and what it does. Do you have more elaborated documentation about the bot itself and the autonomous process? I can't figure the procedure changes on the links provided.

This was just a test PR, should have put it into draft or close it earlier. Done now. Documentation is in work, will be available on the first link before actual roll-out. For now https://github.com/camaraproject/ReleaseManagement/blob/main/documentation/SupportingDocuments/CAMARA-Release-Workflow-and-Metadata-Concept.md is the best available documentation of the overall concept.

Our intention is to participate into the Fall26 with the scope of #111 , changes are not ready yet. So, my I understand that we need to update the YAML file prior to merge.

You could still merge it as is and do an own PR later before your first pre-release for Fall26. But wait for the official roll-out.

In consequence, some practical questions arise:

• Should we update and merge this MR already? Even if the changes are not ready yet?
  No - because this is only a test. Later you can express your next intended (pre)release also when the changes are not ready.

• Does this replace the release issue? Should we link it to the release-plan.yaml somehow?

It replaces directly the release tracker in wiki. And it will be the base for the automated release. There will be a new kind of release issue which will pick up the data from the release-plan.yaml. If you are interested early in the details, you can have a look on camaraproject/ReleaseManagement#362

• Should we need to keep updating the documentation/API_documentation folder and its markdown files?

You mean the API Readiness checklists? ... they will most probably replaced by release-metadata within the release, or we will generate them (mostly). Not finally decided. Other documentation you still need to create and maintain yourself :-)

Thanks in advance! Best regards,

[stroncoso-quobis]

Hi @hdamker ,

Thanks for the comments and the bot, we will wait for the official release then.
I will take a look to camaraproject/ReleaseManagement#362 .

Best regards,