Plugin Migration Guide
Use this hub to select the migration path that matches your current release tool.
Choose your source tool
Section titled “Choose your source tool”| Current tool | Best migration page | Typical migration priority |
|---|---|---|
| semantic-release | From semantic-release to semrel | analyzer + generators first, then publisher parity |
| GoReleaser | From GoReleaser to semrel | build matrix parity, then packaging/publishing split |
| release-please | From release-please to semrel | preserve PR visibility, then switch tag/release owner |
Shared migration baseline
Section titled “Shared migration baseline”All migration paths converge to the same semrel model:
- Updaters prepare version metadata in source/config files
- Packagers build distributable artifacts
- Publishers upload artifacts to registries or HTTP endpoints
Migration Strategy
Section titled “Migration Strategy”- Keep existing updater plugins in place.
- Add a build stage in CI that produces real release artifacts (
dist/,charts/, image tarballs). - Add packager/publisher plugins after build artifacts exist.
- Run first in dry-run mode and compare outputs with your current release flow.
- Enable full release and monitor the first 2-3 releases.
Validation Checklist
Section titled “Validation Checklist”semrel --dry-run releaseprints expected plugin order and artifact paths.- Build artifacts exist before publisher plugins run.
- Registry/endpoint credentials are provided via environment variables.
- Release notes and changelog still contain expected content.
- Rollback path exists (keep previous release workflow for one cycle).