semantic-release vs release-please vs Changesets (and git-cliff)

semantic-release “automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.” It's “meant to be executed on the CI environment after every successful build on the release branch”, and releases only when the commits since the last release call for one.

• By default it uses the Angular commit conventions: fix → patch, feat → minor, and a BREAKING CHANGE: footer → major.
• The default plugins are @semantic-release/commit-analyzer, release-notes-generator, npm and github. The notes land on the GitHub release; a CHANGELOG.md file needs @semantic-release/changelog, and committing it back needs @semantic-release/git.
• Its FAQ “strongly” recommends against committing during a release, because it “adds significant additional complexity to your release process”. Many projects therefore keep notes on GitHub releases only.
• It runs on Node.js (a recent version; check its docs) but can release other kinds of projects through plugins.

A good fit when every merge to main should ship, nobody wants to decide when to release, and your commit messages are reliably conventional. See release notes from Conventional Commits for the commit format.

release-please “maintains Release PRs” that are “kept up-to-date as additional work is merged.” When you merge one, it updates your changelog file and language-specific files such as package.json, “tags the commit with the version number” and “creates a GitHub Release based on the tag”. It “does not handle publication to package managers”, so you add your own publish step to the same workflow.

• It assumes Conventional Commits: fix: → patch, feat: → minor, feat!: or fix!: → major.
• Release types cover many ecosystems, including node, python, java, go, rust and simple (a version.txt and a CHANGELOG.md).
• Before 1.0, bump-minor-pre-major makes breaking changes bump the minor version and bump-patch-for-minor-pre-major makes features bump the patch.
• Monorepos use a manifest: release-please-config.json plus .release-please-manifest.json.
• To force a version, put Release-As: x.x.x in a commit body. To fix a merged pull request's changelog line, add a BEGIN_COMMIT_OVERRIDE … END_COMMIT_OVERRIDE section to its description (this doesn't work with plain merges).

A good fit when a person should decide when to release, you want to review the changelog in a pull request before it ships, or the project isn't JavaScript.

Changesets puts the release decision in the pull request itself: “Instead of parsing git commit messages, change intent is stored in dedicated Markdown files committed alongside your code.” Running changeset asks which packages changed, the semver bump type for each and a summary, and writes a Markdown file with that front matter.

• changeset version “consumes all changesets”, bumps versions “and writes changelog entries for each consumed changeset”. Review the changelog at this point.
• changeset publish “publishes changes to npm, and creates git tags”.
• The changesets/action GitHub Action opens a pull request with versions and changelogs updated, titled “Version Packages” by default.
• It “has a focus on solving these problems for monorepos”, but the workflow also suits single packages.

A good fit when you maintain a monorepo, or contributors' commit messages aren't reliable but you can ask for a one-line summary in each pull request. The npm package changelog guide covers the registry side.

git-cliff generates “changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers.” It's written in Rust, configured in cliff.toml, and renders with Tera templates, so you control every heading and line.

• git cliff --init creates the config; git cliff -o CHANGELOG.md writes the file.
• --unreleased processes commits that don't belong to a tag, --latest starts from the latest tag, --tag sets the tag for the newest version and --bump bumps the version for unreleased changes.
• In a monorepo, run it inside a package directory, or scope it with --include-path and --exclude-path.
• Install it with cargo, npm (git-cliff), pip or Homebrew, or run it in CI with orhun/git-cliff-action.

A good fit when you already tag and publish your own way and only want a better CHANGELOG.md. For a hand-rolled version with plain git commands, see how to generate a changelog from git.

GitHub can draft a release's notes itself: “a list of merged pull requests, a list of contributors to the release, and a link to a full changelog”, grouped by the pull request labels you list in .github/release.yml. From a terminal, gh release create v1.4.0 --generate-notes does the same. Those notes live on GitHub rather than in your repository, so keep a CHANGELOG.md too; Keep a Changelog vs GitHub Releases shows how to run both without double work, and the free LogPulse GitHub Action publishes your CHANGELOG.md section as the release on every tag. It's one workflow step, uses: kalmwerk/release-notes-action@v1 (on GitHub).

Keep a Changelog names these same tools and adds a warning worth keeping: “A generated changelog is raw material at best: a person still has to choose what is notable, group it, and write it for the reader.” Merge related lines, drop internal ones and give every breaking change a migration step; the CHANGELOG.md format guide shows the target.