From release-please to semrel
This guide helps teams transition from release-please to semrel without losing release governance.
Mapping at a glance
Section titled “Mapping at a glance”| release-please behavior | semrel equivalent |
|---|---|
| Release PR with version/changelog updates | semrel analyzer + generator output in CI |
| Tag and release after merge | semrel provider + publish stages |
| PR visibility and review gate | keep branch protection and run semrel post-merge |
Recommended rollout
Section titled “Recommended rollout”- Keep release-please PR flow temporarily for audit visibility.
- Run semrel dry-run on merged PRs and compare version/changelog outputs.
- Move version/changelog ownership to semrel plugins.
- Move publishing and tag ownership to semrel.
- Disable release-please release creation to prevent duplicate tags/releases.
Example plugin baseline
Section titled “Example plugin baseline”plugins: - uses: @semrel/github
- uses: @semrel/conventional
- uses: @semrel/release-notes
- uses: @semrel/changelog-md args: file: CHANGELOG.mdRisks and checks
Section titled “Risks and checks”- Never allow both release-please and semrel to create tags at the same time.
- Verify monorepo package version behavior before cutover.
- Test rollback by keeping the previous workflow file available for one cycle.