prepare-release

name	prepare-release
description	Prepare a CLI11 release — changelog entry, version bump, README feature markers, and related version references.

Prepare a CLI11 release

When preparing a release (chore: prepare X.Y.Z release):

Collect the changes

List the merged PRs since the last release with git log --oneline --first-parent v<last>..main. Every user-visible change gets a changelog line.

Changelog entry

Add a ## Version X.Y.Z: <Short title> section at the top of CHANGELOG.md. The heading becomes the name of the GitHub release, so give it a short title, such as ## Version 2.7.0: Audit and documentation.

• Start with a short prose paragraph that summarizes the release.
• Group the entries under ### Added, ### Changed, ### Fixed, ### Documentation, and ### Internal (and ### Removed/### Deprecated if needed). Documentation covers docs-only changes; Internal covers CI, tests, and tooling changes with no user-visible effect.
• Reference PRs as [#1305][] and put the matching link definitions ([#1305]: https://github.com/CLIUtils/CLI11/pull/1305) at the end of the version section — each section keeps its own definitions so an extracted section needs no fixup.

Version bump

Bump include/CLI/Version.hpp: the CLI11_VERSION_MAJOR/MINOR/PATCH macros and the CLI11_VERSION string.

Other files

• Only if not a patch release: Update the feature markers in README.md: remove the old 🆕 markers (the previous release's features) and change 🚧 markers (main-only features) to 🆕. Removing an emoji from a heading also changes its TOC anchor — drop the trailing - from the matching TOC links.
• Check the copyright year in LICENSE and the version in book/chapters/installation.md.

Verify

CI extracts the release notes from the changelog on every build, so a version bump without a matching changelog section fails. Check locally:

python3 scripts/ExtractReleaseNotes.py --title "$(python3 scripts/ExtractVersion.py)"
python3 scripts/ExtractReleaseNotes.py "$(python3 scripts/ExtractVersion.py)"

After the PR merges

Tell the user to tag the merge commit as vX.Y.Z and push the tag. CI then creates the GitHub release: the name comes from the changelog heading, the body from the changelog section, and the single header plus source packages are attached automatically.