Release Checklist

Release Checklist

Source of truth: https://github.com/appneta/tcpreplay/wiki/Release-Checklist This skill loosely follows it, adapted to what actually happened preparing 4.6.1 on 2026-08-15 — read that as a worked example if anything here is ambiguous.

Ask which of these the user wants before doing anything, since they change the steps: a beta (pre-release, ships from a -betaN branch, no merge to master yet) or a full release (ships from the clean version branch, merges to master after).

1. Readiness check (do this first, always)

• gh run list --branch <branch> --limit 5 — CI green on the latest commit?
• git log origin/master..origin/<branch> --oneline | wc -l — how far ahead of master, and does anything on master need pulling in first (git log origin/<branch>..origin/master --oneline)?
• Read the top of docs/CHANGELOG — does it match the branch's actual state? Any leftover beta-cycle headers that should be squashed into one?
• Report status plainly (ready / blockers) before touching anything. Don't assume "ready to release" means "go ahead and merge" — that's a separate confirmation.

2. Update CHANGELOG (checklist step 4)

• Top entry's date should be the actual release date, version should be the release's clean version number (not -betaN) even for a beta build — the suffix lives in the branch name and the tag, not the CHANGELOG header.
• Remove/squash beta-cycle sub-headers if any accumulated during development — one version header, one list of entries.
• Keep individual entries terse (1-2 lines) unless the user asks otherwise.

3. Update CREDIT (docs/CREDIT)

• Anyone who reported a security advisory (GHSA) fixed in this release gets an entry, grouped by reporter if they filed more than one — see the existing file for the pattern (e.g. tinyb0y, tao pan).
• Automated fuzzer findings (OSS-Fuzz) don't get individual CREDIT entries — they're credited in the CHANGELOG line itself (OSS-Fuzz <issue-id>), not here.

4. Version number (configure.ac)

• AC_INIT([tcpreplay],[X.Y.Z],...) — bump if not already done. Check CMakeLists.txt derives from this automatically (it does, via regex on configure.ac's version) rather than hardcoding a second copy.

5. Branch merges

Order matters less than making sure both directions happen before the next step:

• If master has commits the release branch doesn't (e.g. a hotfix merged there directly), merge master into the release branch first.
• Merge the beta/working branch into the clean version branch (e.g. 4.6.1-beta1 → 4.6.1), or create the clean version branch now if it doesn't exist yet.
• Push. Wait for CI green on the pushed branch before anything downstream depends on it.

6. Tagging, building, signing — not yours to do

You cannot create the actual git tag, build tarballs, or sign them — the maintainer does this on a separate system with the signing key. Don't attempt git tag on the release branch. If the user says "I've tagged and built it," treat the tag as fixed: any further commits you make land after it, and you should say so rather than silently pushing past it.

7. PR to master (full release only; skip for a beta)

• gh pr create --base master --head <branch> --title "Release X.Y.Z".
• Check CI on the PR before merging — don't merge on a hunch, wait for green (gh pr checks <number>, poll if needed).
• After merge: run the Delete Merged Branch skill's logic on the head branch, same as any other PR.

8. Release notes and announcement

• Draft release notes matching the style of the most recent actual release (gh release view v<previous> for the template) — highlights, a security table if applicable, a "What's Changed" list, download/verification instructions. Save as a file and hand it to the user rather than trying to create/publish the GitHub Release yourself — they attach it when uploading tarballs.
• If asked to announce: post to https://github.com/appneta/tcpreplay/discussions/categories/announcements via gh discussion create --category Announcements. Note that pinning a discussion has no API — that's a manual step via the ··· menu on the discussion page.
• A short mailing-list-style announcement email (overview, bullet summary, download link) is a nice companion — see 2026-08-15's 4.6.1 announcement for tone.

9. Cleanup

• Check for open GitHub milestones matching this version; close if any exist (often there aren't any — OSS-Fuzz findings and security advisories don't get milestones by default in this repo).
• Confirm docs-deploy.yml's branch trigger list includes wherever the docs source actually lives post-merge (currently master plus whichever beta branch is active) — the live site only rebuilds on push to a listed branch with docs/** or *_opts.def changes.