Release Steps

This page explains the release steps that make up a semantic-release run.

A release lifecycle is the full recurring process that starts from the previous release state and ends with the next release state.
Release steps are the individual phases within one run of that lifecycle.
Some release steps expose lifecycle hooks that plugins can bind to.
Plugins participate by exposing lifecycle methods such as analyzeCommits or publish.

If you are new to the overall model, read How it Works first.

Step sequence

After tests pass and semantic-release starts, it evaluates the repository state and executes release steps in a fixed order.

Release Step	Lifecycle Hook(s)	Purpose
Verify Conditions	`verifyConditions`	Confirm required configuration and credentials are available.
Get Last Release	None	Find the most recent release by reading Git tags and history.
Analyze Commits	`analyzeCommits`	Determine whether to release and which version type to produce.
Verify Release	`verifyRelease`	Validate the computed release metadata before publishing.
Generate Notes	`generateNotes`	Build release notes for the commits included in this release.
Create Git Tag	None	Tag the release version in Git.
Add Channel (Optional)	`addChannel`	Associate the release with a distribution channel when needed.
Prepare	`prepare`	Perform pre-publish updates such as assets or files.
Publish	`publish`	Publish artifacts to configured destinations and channels.
Notify	`success`, `fail`	Report success or failure through provider integrations.

The order is important. A failure in an early step prevents later steps from running.

Optional and conditional steps

Not every release step in the table above runs on every release.

Some release steps are core-only and do not expose lifecycle hooks. Get Last Release is the clearest example.
Some steps expose more than one lifecycle hook. Notify is implemented through the success and fail hooks.
Some release steps are conditional. The Add Channel release step is an example; it runs only when channel management behavior is needed.

How steps are implemented

Release steps are executed by a combination of core behavior and plugins.

Core handles some behavior directly, including steps that are not exposed as hooks
analyzeCommits is required to decide version impact
Most hook-backed steps depend on which plugins you configure
If multiple plugins implement the same lifecycle hook, they execute in plugin order

For plugin responsibilities and execution details, see Plugins.

Release decision logic

The analyzeCommits step is the decision point for whether a release is created.

The examples below assume the default Conventional Commits mapping and that the highest-impact commit type since the last release determines the version bump

No relevant commits since the last release means no new release
fix commits result in a patch release
feat commits result in a minor release
BREAKING CHANGE results in a major release

Commit parsing depends on your configured commit analyzer and presets. See How it Works for the conceptual model and Configuration for setup details.

Branch and channel impact

The same steps run regardless of branch type, but release outcomes vary with branch strategy and channel configuration.

Release branches publish regular versions
Maintenance branches publish within defined ranges
Pre-release branches publish pre-release identifiers

See Supported Branching Models and Release Workflow Configuration for branch behavior and constraints.

Operational expectations

To keep releases deterministic, run semantic-release only in CI and only after all required checks pass.

For implementation guidance, see: