Overview
We use Release Please to automate releases. When you push tomaster
, Release Please automatically:
- Parses commit messages for conventional commits
- Creates/updates a Release PR with version bumps and changelog
- Tags and creates a GitHub release when the Release PR is merged
How It Works
1. Write Conventional Commits
Use these prefixes in your commit messages:feat:
- New feature (minor version bump)fix:
- Bug fix (patch version bump)feat!:
orfix!:
- Breaking change (major version bump)chore:
,docs:
,refactor:
- No version bump
2. Push to Master
When commits with releasable changes (feat
, fix
, deps
) are pushed to master, Release Please automatically creates or updates a Release PR.
3. Release PR Lifecycle
Release PRs have status labels:Pending
autorelease: pending
- PR is ready for review/mergeTagged
autorelease: tagged
- PR merged, release taggedPublished
autorelease: published
- GitHub release published4. Merge Release PR
When you merge the Release PR, Release Please:- Updates
CHANGELOG.md
and version files - Creates a git tag with the new version
- Creates a GitHub Release
Best Practices
- Use squash-merge for PRs to maintain clean commit history
- Write clear commit messages that explain the change’s impact
- Review Release PRs before merging to ensure correct version bumps
Manual Version Override
To release a specific version, addRelease-As: x.x.x
to your commit body:
Troubleshooting
No Release PR Created?
1
Check Releasable Commits
Ensure you have
feat:
, fix:
, or deps:
commits2
Remove Stale Labels
Look for old PRs with
autorelease: pending
labels3
Force Rerun
Add
release-please:force-run
label to trigger manuallyFix Release Notes
Edit the merged PR body and add:This allows you to correct commit messages that will appear in the release notes after the fact.