Require a [release-notes] or [no-release-notes] label on PRs

[BChan-0]

This PR is one part of an updated resolution for Issue #3952:

Current Scope

The post-release side is mostly automated now. Once a release is cut, valkey-release-automation updates valkey-hashes, opens the valkey-container PR, and updates the website downloads page.

However, writing the release notes and bumping the version is still done by hand.

For each release, someone has to walk every PR since the last tag, decide which ones are user-facing, drop them into the right section of 00-RELEASENOTES, reword commit titles into something a user can read, pick the upgrade urgency, edit the three macros in src/version.h, and open the PR. The 9.1 cycle had ~88 PRs carrying the release-notes label.

In this PR
All PRs are to be gated such that contributors mark an active decision for whether or not to include their PR in version release notes. This change will be enforced through the CI check added by this PR. Contributors must attach exactly one of either the release-notes or no-release-notes label, the latter being created by a maintainer prior to merging this current PR.

Tentative Future Implementation
Rather than requiring contributors to write their own release notes into a running file on unstable, a workflow will live on valkey-io/valkey-ci-agent to generate notes via LLM with context from PR titles and bodies. The workflow will trigger by manual dispatch with inputs head ref, base branch, tag glob, version, urgency, and date, parsing all PRs with the release-notes label from head until the most recent reachable version release candidate tag. For each labelled PR, Bedrock/Claude will then determine a category of release note and construct a note in the form

• human-readable description by @github handle (#PR number)

Previous release candidates' release notes, pulled from a pre-release branch on valkey-io/valkey, will be placed beneath the latest notes, with a full running list of contributor names and handles (See target formatting). The workflow will then raise a PR to create a frozen pre-release branch (release candidates) or version branch (general access) with updated version macros. Any ambiguities from the AI for categorization or necessity of release notes will be surfaced in warnings within the workflow's PR for human review.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d918da8e-5173-42f6-952a-a4dd7d83ffea

📥 Commits

Reviewing files that changed from the base of the PR and between 3cef28f and 5631a99.

📒 Files selected for processing (1)

• CONTRIBUTING.md

✅ Files skipped from review due to trivial changes (1)

• CONTRIBUTING.md

---

📝 Walkthrough

Walkthrough

Adds a pull-request label check for valkey-io/valkey and updates the contribution guide to require exactly one of release-notes or no-release-notes.

Changes

Release notes label workflow

Layer / File(s)	Summary
Workflow trigger and label check .github/workflows/release-notes-label.yml	The workflow runs on pull request activity, scopes to the repository, cancels concurrent runs per PR, and enforces that exactly one release-notes label is set.
Contribution label guidance CONTRIBUTING.md	The contributing guide adds the same label requirement, notes CI enforcement, and points user-facing changes to release-notes.

Estimated code review effort: 1 (Trivial) | ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: enforcing one of two release-notes labels on PRs.
Description check	✅ Passed	The description is directly related to the changeset and explains the new label-enforcement CI check.
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.

---

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.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.62%. Comparing base (79bca53) to head (5631a99).
⚠️ Report is 17 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #4052      +/-   ##
============================================
- Coverage     76.68%   76.62%   -0.07%     
============================================
  Files           162      162              
  Lines         81021    81101      +80     
============================================
+ Hits          62129    62140      +11     
- Misses        18892    18961      +69     

see 31 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sarthakaggarwal97]

@valkey-io/core-team the proposal is to use the labels to make sure that we make a decision on whether a PR should go into the release notes or not. We can apply release-notes and no-release-notes respectively.

Whenever we will be doing a release, the idea is to use these labels to filter the right PRs, and automatically generate the release notes PR (using AI).

Alternate option we discussed of maintaining a changelog, but I feel it comes with more complexity as we have to handle backports, CVEs etc too. In recent times, we have seen some projects move from changelog to the AI based approach, so I feel we can be AI forward for this work as well.

Please let us know your thoughts about this. Thank you!

[enjoy-binbin]

I am OK with this idea, i'm just worried that [no-release-notes] might clutter the web page, but i guess there's no other way. (Did not review the yml)

[sarthakaggarwal97]

Yes. We atleast need a negative label to make a decision. I did have similar concerns about cluttering but figured Maintainers / Contributors can always try and put the label just before the merging. It doesn't have be that way though.

[zuiderkwast]

I'm OK with this workflow. Let's try it.

I've created the no-release-notes label.

[sarthakaggarwal97]

Yes, let's try it out. In the future, we can always try and rely more on AI to generate notes without label annotations, but this is a good start to make process faster!

[BChan-0]

Pivoting away from this check; we're no longer planning on requiring the labels at this time. Currently, the release-notes generator in valkey-ci-agent treats these two labels as the source of truth when it cuts a release, but includes fallback triage.

At release-cut time, we classify every merged PR in the range by its labels: release-notes hard-includes the PR in the generated notes and no-release-notes hard-excludes it (no-release-notes wins on collision). Excluded PRs are still surfaced in an "Excluded by no-release-notes" table in the cut PR so a maintainer can catch a mislabel. As our resolution in the current approach, anything unlabelled now falls back to AI triage, which judges whether the change is user-facing. AI picks are flagged in the PR body for a human to confirm include/exclude.

We've run the full generator on this repo for recent release lines; each successfully opened as a PR with generated notes, src/version.h bump, and refreshed contributor list. These include the points of review the generator raises for maintainers (low-confidence categorization, release-impact/CVE review, backport-credited notes, and PRs needing triage):

7.2.14: #4246
8.0.10: #4245
8.1.9: #4243
9.0.5: #4247
9.1.1: #4244

[sarthakaggarwal97]

I am going to close this PR. Our experiments with AI based release notes are looking promising to me. Thank you @BChan-0 for all the heavy lifting.