| name | backport-pr |
| description | Backport a fix to hiredis maintenance branches (release/vX.Y.X) and land it as a PR so Release Drafter lists it in the auto-drafted patch release. Use when asked to backport a commit or fix to release lines, create maintenance branches for past versions, or wire up automatic draft releases for them. |
Backport a fix to hiredis maintenance branches
Backports land on release/vX.Y.X maintenance branches and MUST arrive as merged
pull requests — Release Drafter builds the $CHANGES section of a draft release
exclusively from merged PRs found in the last-release-tag...branch-head
comparison. Commits pushed directly to the branch never appear in the changelog
(they only contribute commit authors to $CONTRIBUTORS), and the association
cannot be created after the fact: GitHub links a commit to a PR only when a PR
containing that exact SHA is merged.
Maintenance branch conventions
- One branch per release line, named
release/vX.Y.X (literal X suffix,
e.g. release/v1.0.X), created from the release tag (v1.0.2).
- Skip release candidates (
v1.1.0-rc1) when enumerating versions to backport to.
- Enumerate versions from remote tags (
git ls-remote --tags), not the local
clone — local tags may be stale.
- If a maintenance branch does not exist yet, create it from the newest
non-RC tag of that line and add the Release Drafter setup below before
landing the backport.
Backport flow (per branch)
- Review the fix against each target line before touching anything — the
affected code can differ substantially between release lines, and older
lines may not even be affected. Confirm the vulnerable/buggy code exists
on a line before backporting to it.
- Create a topic branch from the maintenance branch:
backport-<topic>-X.Y.x (e.g. backport-nesting-depth-1.0.x).
git cherry-pick <sha> — preserves original authorship, which is what puts
the original author into the draft's Contributors section. Resolve conflicts
minimally: prefer dropping stale comments or context over restructuring the
surrounding code.- Build and test on every branch:
make hiredis-test && ./hiredis-test.
The FULL suite must pass against a real Redis server — the connection
tests are part of the merge bar, not optional. Before running the tests,
check the server is up with redis-cli ping; if it is not running, STOP
and prompt the user to start it (e.g. redis-server --daemonize yes) —
do not start one yourself, do not skip the connection tests, and do not
proceed to the PR with anything less than a clean -Werror build and a
fully passing suite on every branch.
- Open a PR: base = the maintenance branch, head = the topic branch.
- Title becomes the changelog line — keep the upstream commit subject.
- Label it so it lands in the right changelog category (
bug → "🐛 Bug
Fixes", maintenance, feature, ...); the label must already exist in
the repo.
- Credit the original author and, for security fixes, the reporter in the
PR body.
- Merge with a merge commit (
gh pr merge --merge --delete-branch).
The merge push triggers Release Drafter, which updates the branch's draft.
Do NOT open PRs for CI/infra changes (workflows, release-drafter config) —
push those directly to the maintenance branch. Only functional backports go
through PRs.
Verifying
gh run list --workflow "Release Drafter" --branch release/vX.Y.X for run status.- Draft content:
gh api repos/redis/hiredis/releases --jq '.[] | select(.draft)'
— drafts are invisible to unauthenticated/underprivileged tokens, so an empty
result may mean an auth problem, not missing drafts.
- A correct draft names the next patch version, targets the maintenance branch,
lists each backport PR in its category, and credits both the backporter and
the original commit authors as contributors.
Known gotchas
- The draft's version self-corrects after each published release; no manual
version pinning is needed once
filter-by-range is in place.
