docs: restructure release process to use release branches

[slashpai]

Now that we have stable release v0.1.3 🤞🏻 so I have created release branch https://github.com/rhobs/obs-mcp/tree/release-0.1

This PR update release model where the release branch is created first and all release work (changelog, tagging) happens from it for next releases to manage releases better way

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: slashpai

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [slashpai]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

Warning

Rate limit exceeded

@slashpai has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 34 minutes and 39 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 4c9dd0da-f6d8-466e-9b73-9ab8e993b909

📥 Commits

Reviewing files that changed from the base of the PR and between 169119a and 07f75ac.

📒 Files selected for processing (1)

• RELEASE.md

📝 Walkthrough

Walkthrough

This pull request updates RELEASE.md to document a new release process structured around Semantic Versioning with dedicated release-X.Y branches per minor version. The updated workflow specifies creating release branches from main, optionally generating signed pre-release tags (vX.Y.Z-rc.N) from the release branch, updating CHANGELOG.md via a fork PR targeting the release branch, and creating/signing/pushing version tags after pulling merged changes. The documentation also adds explicit steps for merging changes back to main and bumping dependencies in the openshift-mcp-server project after release publication, replacing the previous fixed-tag and release branch naming conventions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: restructuring the release process to use release branches instead of the previous model.
Description check	✅ Passed	The description is related to the changeset, explaining the context of creating a release branch and updating the release model documentation to reflect the new process.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ 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

_{Review rate limit: 0/1 reviews remaining, refill in 34 minutes and 39 seconds.}

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

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@RELEASE.md`:
- Around line 10-20: Update the ambiguous phrase "latest release branch" under
"Branch management and versioning strategy" to a deterministic rule: replace it
with a statement that bug fixes for released versions must be merged into the
release branch with the highest minor version for the current MAJOR (i.e., the
`release-<MAJOR>.<highest-minor>` branch), clarify that "highest minor" refers
to semver ordering of X.Y, and add a short note describing the fallback when a
newer minor branch hasn’t been cut yet (e.g., if no release branch exists for
the current major, merge fixes into `main` or create the new release-X.Y branch
first).
- Around line 21-27: The fenced ASCII diagram block in RELEASE.md is triggering
markdown lint MD040 because it lacks a language tag; update the opening fence
for the diagram (the triple backticks that start the ASCII diagram block shown
with "main: A---B---C..." etc.) to include a language tag such as text (i.e.,
change ``` to ```text) so the linter stops flagging MD040.

🪄 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: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 13884749-c162-47ef-81fc-6a13957286d2

📥 Commits

Reviewing files that changed from the base of the PR and between 35e099b and 169119a.

📒 Files selected for processing (1)

• RELEASE.md

[slashpai]

/hold

[slashpai]

addressed coderabbit comments
/hold cancel

This is good for review now

[iNecas]

Isn't this unnecessary complicated? Wouldn't it be better to always get everything to master and cherrypick things that would be worth backporting (which is the model openshift-mcp is taking afaik?).

[slashpai]

Ok, that's fine too.
I was using a usual upstream approach used here.

[iNecas]

I depends on definition of usual (non of the upstreams I've been part of followed this pattern:) Out of curiosity, what repository/project you have in mind as an inspiration? I would be curious on what's the experience there.

Said that, I would really recommend the simpler model, unless there is some big win in the release process to do it this way.

[slashpai]

like in prometheus-operator :), also in prometheus https://github.com/prometheus/prometheus/blob/main/RELEASE.md

But for obs-mcp we can follow a simple approach if thats preferred.

Edit:

But a few adavantages of this approach I wanted to highlight and we can decide :)

• Latest release branch gets the fix first and we can do immediate release without worrying of changes in main (cherrypicking to release branch becomes tricky when main is ahead of release branch very much). I see this as main reason for this approach because main may not be in a state to do immediate release but release branch will be a stable one and we can do quick release in case of bugfixes.

• The merge-back step guarantees main always has every fix. With the reverse approach (fix in main, cherry-pick to release), someone might forget to cherry-pick and the release branch stays broken.

• Cleaner git history

The tradeoff is contributors must target the release branch for bug fixes, not main. If someone accidentally merges a fix to main first, you need to cherry-pick to the release branch and merge back.

[saswatamcode]

for reference https://thanos.io/tip/thanos/release-process.md/#how-to-release-a-version

[slashpai]

Thanos also follows like Prometheus IIUC :)

We can keep it simple for obs-mcp. May be backport only needed fixes to release branch and be ready to release from main any time? :)