semantic-release vs lerna vs @changesets/cli vs release-it vs standard-version
Automated Versioning and Release Management Comparison
1 Year
semantic-releaselerna@changesets/clirelease-itstandard-versionSimilar Packages:
What's Automated Versioning and Release Management?

Automated versioning and release management tools help developers manage the process of versioning their software projects and publishing updates. These tools can automate tasks such as determining the next version number based on changes made, generating changelogs, and publishing packages to registries. This automation reduces manual effort, ensures consistency, and helps teams adhere to best practices in versioning and release processes.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
semantic-release2,086,82922,219291 kB37612 days agoMIT
lerna1,974,35135,9728.39 MB39712 days agoMIT
@changesets/cli1,392,65010,322130 kB50721 days agoMIT
release-it755,9398,530316 kB39a month agoMIT
standard-version645,8137,857136 kB310-ISC
Feature Comparison: semantic-release vs lerna vs @changesets/cli vs release-it vs standard-version

Versioning Strategy

  • semantic-release:

    semantic-release automates versioning entirely based on commit messages. It uses a conventional commit style to determine the next version number automatically.

  • lerna:

    lerna supports both fixed and independent versioning strategies. It allows you to choose a single version for all packages or version them independently based on changes.

  • @changesets/cli:

    @changesets/cli allows for manual versioning with a focus on collaboration. It lets developers decide version numbers and supports multiple versioning strategies (major, minor, patch) per package.

  • release-it:

    release-it is flexible and supports manual and automated versioning. You can configure it to use semantic versioning, manual versioning, or a combination of both.

  • standard-version:

    standard-version automates versioning based on conventional commit messages but requires a manual trigger to create a new release.

Changelog Generation

  • semantic-release:

    semantic-release generates changelogs automatically based on commit messages. It creates a detailed changelog that reflects the changes made in each release.

  • lerna:

    lerna can generate changelogs, but it requires additional configuration and is not as automated as other tools. It works best when combined with other changelog generators.

  • @changesets/cli:

    @changesets/cli generates changelogs based on the changesets created by developers. It provides a clear and customizable changelog format.

  • release-it:

    release-it can generate changelogs automatically during the release process. It supports custom templates and integrates well with other tools.

  • standard-version:

    standard-version generates changelogs based on conventional commit messages. It creates a changelog file as part of the versioning process.

Monorepo Support

  • semantic-release:

    semantic-release can be used in monorepos, but it requires additional configuration to handle multiple packages and their versioning.

  • lerna:

    lerna is built for monorepos and provides extensive features for managing multiple packages, including versioning, publishing, and handling inter-package dependencies.

  • @changesets/cli:

    @changesets/cli supports monorepos but is not specifically designed for them. It works well with multiple packages in a single repository.

  • release-it:

    release-it can be used in monorepos but does not provide specific features for managing multiple packages. It works well with any project structure.

  • standard-version:

    standard-version can be used in monorepos but does not provide specific features for managing multiple packages. It works well with any project structure.

Customization and Extensibility

  • semantic-release:

    semantic-release is customizable, especially in terms of plugins. It allows developers to define their workflows and integrate with other tools.

  • lerna:

    lerna is extensible and allows for customization of its workflows. It can be integrated with other tools and scripts to enhance its functionality.

  • @changesets/cli:

    @changesets/cli is customizable and allows developers to define their versioning and changelog generation processes. It supports plugins and integrations with other tools.

  • release-it:

    release-it is highly customizable and supports plugins, scripts, and configuration files. It allows for extensive customization of the release process.

  • standard-version:

    standard-version is customizable but has a more limited scope compared to other tools. It allows for configuration of versioning and changelog generation.

Ease of Setup

  • semantic-release:

    semantic-release requires a more complex setup, especially for CI/CD integration. It needs configuration for commit message conventions and automated releases.

  • lerna:

    lerna requires more setup, especially for monorepos. It may require additional configuration for publishing and managing dependencies.

  • @changesets/cli:

    @changesets/cli is easy to set up and requires minimal configuration. It integrates well with existing Git workflows.

  • release-it:

    release-it is easy to set up and can be configured quickly. It integrates well with CI/CD pipelines and supports command-line usage.

  • standard-version:

    standard-version is easy to set up and requires minimal configuration. It works well with existing Git workflows.

Ease of Use: Code Examples

  • semantic-release:

    Example of using semantic-release to automate releases:

    # Install semantic-release
    npm install --save-dev semantic-release
    
    # Configure semantic-release in package.json
    "release": {
      "semantic-release": {}
    }
    
    # Run semantic-release
    npx semantic-release
    
  • lerna:

    Example of using lerna to version and publish packages:

    # Install Lerna
    npm install --global lerna
    
    # Initialize a Lerna project
    lerna init
    
    # Version packages
    lerna version
    
    # Publish packages
    lerna publish
    
  • @changesets/cli:

    Example of using @changesets/cli to create a changeset:

    # Install the package
    npm install @changesets/cli
    
    # Initialize changesets
    npx changeset init
    
    # Create a changeset
    npx changeset
    
    # Version and publish
    npx changeset version
    npx changeset publish
    
  • release-it:

    Example of using release-it to create a release:

    # Install release-it
    npm install --save-dev release-it
    
    # Configure release-it in package.json
    "release": {
      "scripts": {
        "release": "release-it"
      }
    }
    
    # Run release-it
    npm run release
    
  • standard-version:

    Example of using standard-version to version and release:

    # Install standard-version
    npm install --save-dev standard-version
    
    # Configure standard-version in package.json
    "release": {
      "standard-version": {}
    }
    
    # Run standard-version
    npm run release
    
How to Choose: semantic-release vs lerna vs @changesets/cli vs release-it vs standard-version
  • semantic-release:

    Choose semantic-release if you want a fully automated release process that determines versioning and changelog generation based on commit messages, enforcing a conventional commit style for consistency.

  • lerna:

    Choose lerna if you are working with a monorepo and need a comprehensive solution for managing multiple packages, including versioning, publishing, and handling dependencies between packages.

  • @changesets/cli:

    Choose @changesets/cli if you want a simple and flexible tool that integrates well with Git and allows for manual versioning with a focus on collaboration and changelog generation.

  • release-it:

    Choose release-it if you need a highly customizable and scriptable release tool that supports multiple versioning strategies, changelog generation, and can be easily integrated into CI/CD pipelines.

  • standard-version:

    Choose standard-version if you prefer a simple, convention-based approach to versioning and changelog generation without the need for a separate CI/CD setup.

README for semantic-release

📦🚀 semantic-release

Fully automated version management and package publishing

Join the community on GitHub Discussions Build states OpenSSF Scorecard semantic-release: angular

npm latest version npm next version npm beta version

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.

This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification and communicating the impact of changes to consumers.

Trust us, this will change your workflow for the better. – egghead.io

Highlights

How does it work?

Commit message format

semantic-release uses the commit messages to determine the consumer impact of changes in the codebase. Following formalized conventions for commit messages, semantic-release automatically determines the next semantic version number, generates a changelog and publishes the release.

By default, semantic-release uses Angular Commit Message Conventions. The commit message format can be changed with the preset or config options of the @semantic-release/commit-analyzer and @semantic-release/release-notes-generator plugins.

Tools such as commitizen or commitlint can be used to help contributors and enforce valid commit messages.

The table below shows which commit message gets you which release type when semantic-release runs (using the default configuration):

| Commit message | Release type | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | fix(pencil): stop graphite breaking when too much pressure applied | ~~Patch~~ Fix Release | | feat(pencil): add 'graphiteWidth' option | ~~Minor~~ Feature Release | | perf(pencil): remove graphiteWidth option

BREAKING CHANGE: The graphiteWidth option has been removed.
The default graphite width of 10mm is always used for performance reasons. | ~~Major~~ Breaking Release
(Note that the BREAKING CHANGE: token must be in the footer of the commit) |

Automation with CI

semantic-release is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be unromantic and unsentimental.

Triggering a release

For each new commit added to one of the release branches (for example: master, main, next, beta), with git push or by merging a pull request or merging from another branch, a CI build is triggered and runs the semantic-release command to make a release if there are codebase changes since the last release that affect the package functionalities.

semantic-release offers various ways to control the timing, the content and the audience of published releases. See example workflows in the following recipes:

Release steps

After running the tests, the command semantic-release will execute the following steps:

| Step | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Verify Conditions | Verify all the conditions to proceed with the release. | | Get last release | Obtain the commit corresponding to the last release by analyzing Git tags. | | Analyze commits | Determine the type of release based on the commits added since the last release. | | Verify release | Verify the release conformity. | | Generate notes | Generate release notes for the commits added since the last release. | | Create Git tag | Create a Git tag corresponding to the new release version. | | Prepare | Prepare the release. | | Publish | Publish the release. | | Notify | Notify of new releases or errors. |

Requirements

In order to use semantic-release you need:

Documentation

Get help

Badge

Let people know that your package is published using semantic-release and which commit-convention is followed by including this badge in your readme.

semantic-release: angular

[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release)

Team

| Gregor Martynus | Pierre Vanduynslager | Matt Travi | | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | | Gregor Martynus | Pierre Vanduynslager | Matt Travi |

Alumni

| Stephan Bönnemann | Rolf Erik Lekang | Johannes Jörg Schmidt | Finn Pauls | Christoph Witzko | | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Stephan Bönnemann | Rolf Erik Lekang | Johannes Jörg Schmidt | Finn Pauls | Christoph Witzko |

Kill all humans