standard-version

Automate versioning and CHANGELOG generation

TLDR

Update the changelog file and tag a release

$ standard-version

Tag a release without bumping the version

$ standard-version --first-release

Update the changelog and tag an alpha release

$ standard-version --prerelease alpha

Update the changelog and tag a specific release type

$ standard-version --release-as [major|minor|patch]

Tag a release, preventing hooks from being verified during the commit step

$ standard-version --no-verify

Tag a release committing all staged changes, not just files affected by standard-version

$ standard-version --commit-all

Update a specific changelog file and tag a release

$ standard-version --infile [path/to/file.md]

Display the release that would be performed without performing them

$ standard-version --dry-run

--help
    Display help information.

--version
    Display the version number.

-f, --first-release
    Generate a CHANGELOG for the first release.

-a, --all
    Generate CHANGELOG including prereleases.

-i, --infile
    Specify the CHANGELOG file (default: CHANGELOG.md).

-s, --silent
    Suppress output.

-v, --verbose
    Verbose output.

--message
    Specify a commit message.

--sign
    Sign the commit with GPG.

--no-verify
    Bypass git's pre-commit or commit-msg hooks.

DESCRIPTION

standard-version is a command-line tool designed to automate the versioning of software projects and the generation of CHANGELOG files. It uses conventional commits (a standardized format for commit messages) to determine the next semantic version number and to populate the CHANGELOG with meaningful entries. This significantly reduces the manual effort involved in releasing new versions of a project.

The tool analyzes commit history, bumps the version number in relevant files (e.g., package.json), generates a CHANGELOG entry based on the commits since the last release, commits these changes, and optionally creates a tag for the new version. It's commonly used in JavaScript projects using npm or yarn but can be adapted to other programming languages and environments. It aims to streamline the release process and ensure consistent and accurate versioning and release notes.

CAVEATS

standard-version requires a clean git working directory. Uncommitted changes will prevent it from running. It also depends on conventional commit messages being followed for accurate CHANGELOG generation.

CONFIGURATION

standard-version can be configured via a package.json entry under the 'standard-version' key, or via a dedicated configuration file (e.g., .standard-versionrc.json). This allows customization of the version bump files, commit message format, and other behaviors.

CONVENTIONAL COMMITS

standard-version relies on conventional commit messages to determine the semantic version bump (major, minor, patch) and categorize CHANGELOG entries. Common types include 'feat' (new feature), 'fix' (bug fix), 'docs' (documentation changes), and 'BREAKING CHANGE' (indicating a major version bump).

HISTORY

standard-version emerged to address the need for automated versioning and CHANGELOG generation, particularly in the context of Node.js and JavaScript projects. It builds on the principles of semantic versioning and conventional commits, aiming to simplify the release process and improve the accuracy of release notes. The project has evolved to support various configuration options and customization, making it adaptable to different project requirements and workflows.