semantic-release vs release-please: Automated Releases in CI
Both automate versioning from Conventional Commits, but semantic-release publishes straight from CI while release-please proposes a reviewable release PR.
semantic-release analyzes commits and publishes a new version (changelog, tags, registry) automatically on push. release-please (Google) instead opens and maintains a release PR; merging it cuts the release, keeping a human gate.
| semantic-release | release-please | |
|---|---|---|
| Release trigger | Auto on push to release branch | Merge the release PR |
| Human gate | None by default | Yes (review the PR) |
| Changelog/versioning | From commits | From commits |
| Publish step | Built into the run | After PR merge |
| Best for | Fully automated pipelines | Reviewed, batched releases |
In CI
semantic-release is fully hands-off: push conforming commits and it versions, tags, and publishes in the same job. release-please keeps a human in the loop by maintaining a release PR that batches changes and a changelog until you merge, which suits teams that want to review what ships. Both rely on Conventional Commits and run as a CI step.
CI setup
Give the release job the right tokens/permissions to tag and publish, and pin the tool version for reproducibility. The release job runs on CI runners; faster managed runners shorten release builds that also compile or bundle artifacts.
The verdict
Want fully automated publish straight from CI: semantic-release. Want a reviewable, batched release PR as a gate: release-please. Both use Conventional Commits - choose by how much human control you want over each release.