standard-version vs semantic-release: Versioning
standard-version bumps the version and changelog locally when you choose; semantic-release fully automates versioning and publishing from commit history in CI.
standard-version reads Conventional Commits to bump the version, update the changelog, and tag - but you run it and push the release, keeping a human in the loop. semantic-release takes over the whole pipeline: in CI it determines the next version from commits, generates notes, publishes to npm, and creates the GitHub release with no manual step. standard-version offers control; semantic-release offers full automation. (standard-version is now deprecated in favor of forks, but the model is widely used.)
| standard-version | semantic-release | |
|---|---|---|
| Trigger | Manual (you run it) | Automatic in CI |
| Publishing | You push/publish | Fully automated |
| Control | High (human gate) | Low (hands-off) |
| Setup | Simple | More plugins/config |
| Best for | Controlled releases | Continuous delivery |
In CI
semantic-release is built for CI: merge to the release branch and it versions, tags, publishes, and notes automatically, which is ideal for continuous delivery. standard-version fits teams who want commit-driven bumps but a human deciding when to cut and push a release. Both depend on disciplined Conventional Commits.
Speed it up
Cache dependencies so the release job starts quickly; both publish from a build that runs on CI runners, and faster managed runners shorten the build and publish steps.
The verdict
Wanting fully automated, hands-off publishing on every qualifying merge: semantic-release. Wanting commit-driven version and changelog bumps but a human deciding when to release: standard-version (or a maintained fork). Choose by how much manual control you want over cutting releases.