feat: Automate release‑candidate version bump & release‑note guard

[Amnah199]

Background
Updating the VERSION.txt file from one release‑candidate tag (e.g. 2.3.0‑rc0) to the next (2.3.0‑rc1) is still a manual step. Likewise, the check of at least one new release note between the two tags is needs to be performed manually. if it’s forgotten, the github_release workflow fails later with a Reno KeyError.

Proposal
Create a GitHub Actions workflow that:

• Reads the current version in VERSION.txt on the release branch (e.g. v2.3.x).
• Computes the next ‑rc version (increment the trailing rc integer).
• (If possible )Verifies that there is a release note between two rc tags.
• Updates VERSION.txt, commits the change on the same branch, and pushes it back to GitHub (see below).
  git add . && git commit -m "bump version to 2.3.0-rc1" && git push origin v2.3.x

Criteria

• A new workflow file at .github/workflows/bump-rc-version.yml.
• Triggered manually via workflow_dispatch, with an optional input to override the computed next‑rc value.
• Uses the GitHub token to open a commit on the current release branch (vX.Y.x).
• If Reno finds no release notes between tags, the job fails with a clear error message.
• On success, the workflow commits bump version to <next‑rc> and pushes it.
• Documentation (Notion) is updated to describe the automated bump & note‑check.

[YassinNouh21]

@Amnah199
I just want to make sure that my impl is correct

I've implemented a GitHub Actions workflow (.github/workflows/bump-rc-version.yml) that fully addresses the proposal and criteria described in this issue:

What the workflow does:

• Reads VERSION.txt to extract the current RC version and parse base_version / rc_number.
• Computes the next RC version, e.g. 2.3.0-rc0 → 2.3.0-rc1, unless an override_version is provided via workflow_dispatch.
• Uses reno to validate the existence of at least one release note between the latest RC tag and HEAD. If none found, it exits early with a clear error (prevents downstream Reno KeyError).
• Updates VERSION.txt, commits the change, and pushes directly to the same branch.
• Checks for release branch naming (vX.Y.x), issuing a warning if the branch does not conform.

[Amnah199]

@YassinNouh21 You seem to be on the right track. Feel free to open a PR, and we’ll review it.

[Amnah199]

@YassinNouh21 There's an active Haystack Discord channel where you can post any questions. Our team will respond to you there.

[YassinNouh21]

@YassinNouh21 There's an active Haystack Discord channel where you can post any questions. Our team will respond to you there.

thanks for sharing

[anakin87]

the check of at least one new release note between the two tags is needs to be performed manually. if it’s forgotten, the github_release workflow fails later with a Reno KeyError.

Updates:
1. This seems to happen with release candidates (2.20.0-rc2) and not for final minor releases (2.20.0). Plus, it only means that the rc release won’t be created on GitHub. For these reasons, blocking the release seems excessive.
2. After some testing with a local repository, I am unable to reproduce the error. In addition, much time has passed since this workflow failed, so we cannot inspect logs. For this reason, I suggest not treating this problem now but figure out a solution next time it happens. Seems reasonable because it seems to never happen on final releases but only on rcs and does not block the release.
3. In short, I cannot reproduce this. I also think that with the new release note generation (#10107) + making release candidates mandatory, this won’t happen again.