Add RELEASE.md documentation

[Priyanshu-u07]

Adds a RELEASE.md documenting the release process for kuadrant-backstage-plugin.

Closes #329

Summary by CodeRabbit

• Documentation
  • Added comprehensive release procedures documentation for the kuadrant-backstage-plugin, detailing the complete workflow including release preparation, GitHub Actions automation, multi-package npm publishing configuration, dev build publishing options, and post-release version management processes.

[coderabbitai]

Warning

Review limit reached

@Priyanshu-u07, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 52 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 9fea067f-7b93-4d39-9156-a06f2d96e69b

📥 Commits

Reviewing files that changed from the base of the PR and between 08ba35e and 7d5c454.

📒 Files selected for processing (1)

• RELEASE.md

📝 Walkthrough

Walkthrough

A new RELEASE.md file is added to the repository, documenting the complete release process for the kuadrant-backstage-plugin. It covers preparing a release commit, triggering the GitHub Actions workflow, npm publishing (automatic and manual dev builds), post-release version bumps, and a summary table of all steps and triggers.

Changes

Release Process Documentation

Layer / File(s)

Summary

Release process documentation RELEASE.md

Adds the full release procedure: removing -dev suffixes from both plugin package.json files, triggering the workflow_dispatch release workflow (version/tag checks, build, tarball, changelog, GitHub Release), automatic npm publishing of three packages with the latest dist-tag, an optional manual dev build publish using version + short SHA with the dev dist-tag, and the post-release step to bump both plugin versions to the next -dev version via a PR. Concludes with a summary table of steps and triggers.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐇 A scroll of steps, now written clear,
Release the plugin without fear!
Remove the -dev, dispatch the flow,
Watch the tarballs come and go.
Bump the version, off we hop —
The bunny's work shall never stop! 🎉

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding RELEASE.md documentation to the repository.
Linked Issues check	✅ Passed	The PR addresses all key requirements from issue #329: documents release branch workflow, version bumping, triggering minor/patch releases, published artifacts, and manual steps.
Out of Scope Changes check	✅ Passed	The changes are limited to adding RELEASE.md documentation and are directly aligned with issue #329 objectives; no out-of-scope modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

RELEASE.md (2)

49-54: ⚡ Quick win

Point the bump step at the existing automation.

The repo already provides yarn versions:bump / node ./scripts/update-backstage.mjs; documenting that command instead of hand-editing both package.json files would reduce drift and keep the version updates in sync.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@RELEASE.md` around lines 49 - 54, In the "Bump to the Next Development
Version" section of RELEASE.md, replace the instruction that tells users to
manually update the version field in both plugin package.json files with the
`-dev` suffix. Instead, document the use of the existing automation commands
(yarn versions:bump or node ./scripts/update-backstage.mjs) to perform the
version bump. This ensures version updates remain consistent across both files
and reduces the risk of manual errors causing drift.

---

12-15: ⚡ Quick win

Document the release branch convention explicitly.

This step only mentions main, but the PR objective calls out release-X.Y-style release branches. Please add that flow here so people do not follow the wrong branch model.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@RELEASE.md` around lines 12 - 15, The current instructions in the section
describing where to push the commit only mention pushing directly to `main`, but
do not document the `release-X.Y` style release branch convention referenced in
the PR objectives. Add an explicit bullet point or flow option that describes
the release branch model as an alternative to pushing to main, clearly
explaining the `release-X.Y` naming convention and when this approach should be
used instead of pushing directly to main. This will help users follow the
correct branch model for releases.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@RELEASE.md`:
- Around line 45-47: The version example in the manual workflow_dispatch
documentation is misleading because it assumes the base version is `0.0.2`, but
if `plugins/kuadrant/package.json` already contains a dev suffix (like
`0.0.2-dev`), the resulting published version would append the short SHA to that
existing version, resulting in `0.0.2-dev-abc1234` instead of `0.0.2-abc1234`.
Update the example in the RELEASE.md file to clarify that the short Git SHA is
appended to whatever the current `package.json` version is, including any
existing suffixes, to accurately represent the behavior.

---

Nitpick comments:
In `@RELEASE.md`:
- Around line 49-54: In the "Bump to the Next Development Version" section of
RELEASE.md, replace the instruction that tells users to manually update the
version field in both plugin package.json files with the `-dev` suffix. Instead,
document the use of the existing automation commands (yarn versions:bump or node
./scripts/update-backstage.mjs) to perform the version bump. This ensures
version updates remain consistent across both files and reduces the risk of
manual errors causing drift.
- Around line 12-15: The current instructions in the section describing where to
push the commit only mention pushing directly to `main`, but do not document the
`release-X.Y` style release branch convention referenced in the PR objectives.
Add an explicit bullet point or flow option that describes the release branch
model as an alternative to pushing to main, clearly explaining the `release-X.Y`
naming convention and when this approach should be used instead of pushing
directly to main. This will help users follow the correct branch model for
releases.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1e38e914-91a4-40eb-ac62-ef3238d7b94e

📥 Commits

Reviewing files that changed from the base of the PR and between 18c7ab0 and 08ba35e.

📒 Files selected for processing (1)

• RELEASE.md