release notes generated from wrong tag range, release failed review

TL;DR

Regenerate the notes from the correct range - previous release tag to the new tag - and resubmit for review. A wrong range pulls in old commits or misses this release's changes, and reviewers rightly reject notes that do not describe the release. Verify the range with git log PREV..NEW --oneline before regenerating, and pin the base tag in the release workflow.

The error

release notes generated from wrong tag range, release failed review

Steps

1. Identify the correct tags: git tag --sort=-v:refname | head -5. Expected: you know the previous release tag and the new tag with certainty.
2. Inspect the range: git log v1.4.0..v1.5.0 --oneline (your actual tags). Expected: the list matches exactly the changes this release should describe - no older commits, nothing missing.
3. Regenerate with the explicit range: pass the correct previous and current tags to your changelog tool, or set the base to the previous tag when generating notes on your git host. Expected: the new notes cover only the verified range.
4. Diff the new notes against the rejected ones. Expected: the wrongly included commits are gone and the missing ones are present.
5. Resubmit for review. Expected: the notes now describe the release accurately and review passes.

Use this when

• Release notes were rejected because they describe the wrong set of changes.
• Auto-generated notes include commits from older releases.
• The notes miss changes that definitely shipped in this release.

Not for this skill when

• The range is correct but the wording is bad - that is an editing pass, not a range fix.
• You are deciding what counts as the "previous release" in a complex branching model - that is a release-process decision.
• The notes are hand-written; just rewrite the wrong parts.

Variant phrasings

release notes cover the wrong commits

Same range problem, stated plainly. Same fix.

generated notes include old changes

Same, with the most common symptom named. Same fix.

wrong base tag on release notes

Same, naming the usual root cause. Same fix.

Why it happens

"Generate from the last release" is a heuristic: the tool guesses which tag is the base. Deleted tags, releases cut from maintenance branches, and version numbers that do not sort lexically (v1.10.0 vs v1.9.0) all make the heuristic pick the wrong base. The generator then works correctly on an incorrect range, which looks like a content bug but is an input bug.

Edge cases

• Pre-releases: generating final-release notes from the last pre-release tag instead of the last stable tag duplicates the pre-release entries. Base final notes on the last stable tag.
• The first release has no previous tag; generators fall back to the beginning of history or fail. Set the base explicitly for v1.0.0.
• Tag sorting: v1.10.0 sorts before v1.9.0 lexically. Use version-aware sort when picking tags by hand.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstotkvxNe4fKc57C22Pcu9Q