If it doesn't exist locally, create it from upstream:
git checkout -b <branch> upstream/<branch>
The tip is if it exists, otherwise .
The is the merge-base of the tip with .
Collect the full commit list:
release-$NEW_MINOR
main
base
release-$PREV_MINOR
git log --oneline --no-merges <base>..<tip>
Phase 2 -- Exclude backported commits
Run the companion script to remove commits that were cherry-picked or
backported to the previous release branch (they already shipped in a patch
release):
The script handles automated backports (chore(backport ...): prefix,
resolving original PR numbers via the backport PR body), manual backports
(chore: manually backport #NNNN:), "Merge commit from fork" entries,
and backport entries on the tip branch. It reports a summary to stderr.
Report the counts to the user.
Phase 3 -- Preliminary classification
Run the companion script to classify commits by subject line alone (no API
calls needed):
The script auto-excludes docs, deps, CI, typo, and chore commits;
auto-includes features and breaking changes; and sends the rest to
uncertain. It reports counts to stderr.
Report the counts to the user.
Phase 4 -- Enrich and classify remaining commits
GitHub authentication
Before fetching any GitHub data, verify that gh is authenticated and has
access to the akuity/kargo repository by running a test API call:
gh api repos/akuity/kargo --jq '.full_name'
If this fails for any reason -- SAML enforcement, expired token, missing
scopes, no gh CLI, etc. -- do not silently fall back to local-only
data. Instead:
Tell the user exactly what went wrong.
Suggest the user try gh auth refresh to reauthorize via the browser.
Re-run the test call after they do.
If that doesn't work, ask the user to provide a GitHub personal access
token authorized for the akuity organization. Either kind works:
Fine-grained (recommended): scoped to akuity/kargo with
read-only repository access. Authorized for the org at creation time.
Classic: with repo scope, then separately authorized for the
akuity org's SAML SSO.
Once the user provides a token, set it for the remainder of the session:
export GH_TOKEN=<token>
Re-run the test call to confirm it works.
If it still fails, ask the user to troubleshoot -- do not proceed without
GitHub API access. PR and issue context is essential for writing quality
release notes.
Fetch PR and issue metadata
Run the companion script to fetch PR details and linked issues for all
auto-included and uncertain commits:
The script creates pr-NNNN.json and issue-NNNN.json files in the
output directory, plus an index.tsv summary. It is idempotent (skips
already-fetched PRs).
Classify unclassified commits
Read the fetched metadata (/tmp/kargo-rn/metadata/) and classify the
uncertain commits using PR body, labels, linked issues, and diff stats:
Auto-exclude: minor bug fixes that appear routine (small diff,
not touching user-facing behavior significantly). Use the PR body and
linked issue (if any) to judge significance -- a bug fix linked to an
issue with many reactions or comments may be noteworthy.
Also exclude: internal refactors with no user-facing change.
The script finds all author emails in the range, filters bots, checks for
prior commits before the base, and maps each first-time email to a GitHub
login deterministically (commit SHA → GitHub API). Output is email|login
lines. Use only this mapping for the contributor list -- do not
cross-reference or override it with PR author logins or other heuristics.
Phase 6 -- Group and draft
Read prior release notes for tone
Before writing, re-read docs/docs/80-release-notes/ for the two most
recent minor versions. Match their tone, structure, emoji usage, and level of
detail.
Determine the file name
Release notes files use descending numeric prefixes. Read the existing files
in docs/docs/80-release-notes/ and choose a prefix one less than the
current lowest-numbered version file (e.g. if 90-v1.9.0.md exists, use
89-v1.10.0.md).
Structure
The release notes file should NOT have YAML frontmatter (matching the pattern
of recent release notes files). Start with a one- or two-sentence intro with
a rocket emoji.
Organize the included changes into sections and subsections that make sense
for the content. Use the prior release notes as a guide for the kinds of
sections and headings that work well, but adapt to fit the actual changes --
don't force content into a rigid template. Always end with a Special Thanks
section for first-time contributors (if any).
Use emoji in section and subsection headings where a sensible one exists.
The tone should be light and positive -- release notes are a celebration of
what shipped.
Writing guidelines
Use PR and issue context for narratives. The PR description explains
what and why; the linked issue explains the user's original problem. Lead
with the user benefit derived from the issue, then describe the solution
using the PR context. Do not copy PR text verbatim -- distill it into
concise, user-facing language.
For breaking changes and deprecations, always state:
What changed or will change
Why (brief rationale -- often found in the PR body)
What to do about it (migration path or link to docs)
When deprecated features will be removed
Link to relevant documentation sections using https://docs.kargo.io/...
URLs. Find the right doc path by searching docs/docs/ for the relevant
content.
For features, lead with the user benefit, not the implementation detail.
Keep descriptions concise -- a sentence or two plus a docs link.
Use @username for contributor mentions.
"Freight" is a mass noun -- never "freights" or "a freight."
Say "promote" not "deploy" when describing what Kargo does.
where PREV_LATEST is the latest tag on upstream/release-$PREV_MINOR:
git tag --list "v$PREV_MINOR.*" --sort=-v:refname | head -1
Update the deprecations page
If there are new deprecations or breaking changes involving removals of
previously deprecated features, update
docs/docs/80-release-notes/100-deprecations.md to reflect them, following
the existing table format.
Phase 7 -- Present for review
Show the complete draft.
Summarize: number of commits analyzed, excluded, included; number of
PRs and issues consulted; number of first-time contributors found.
Do not commit automatically -- wait for the user to review, suggest
edits, and approve.