![\"Release](\"https://github.com/ossjs/release/blob/main/logo.png?raw=true\"){kind=logo}
\n\n \n
Minimalistic, opinionated, and predictable release automation tool.
\n\n## Motivation\n\nI created Release because I wanted an easy and reliable way to publish my libraries. Over the years, I've tried every release automation tool out there and found a bunch of issues, ideological mismatches, and lacking developer experience in every one of them. I've grown so tired solving release bugs that I decided it would be more productive to create my own tool and, turns out, it was! I've been using Release for my projects ever since and never looked back. It does exactly what I want, the way I want it.\n\nYou can keep reading to learn more about what Release does differently, jump to the [Getting started](#getting-started) section, or read how it [compares to the alternatives](#comparison).\n\n## Release flow\n\nRelease performs the following release flow:\n\n1. Analyze commits since the last published release (tag);\n1. Determine the next package version per [Conventional Commits](https://www.conventionalcommits.org/);\n1. Verify that the branch is in sync with its remote counterpart;\n1. Lint your package via `publint` to prevent publishing broken packages;\n1. Run your publishing script (e.g. `npm publish`);\n1. Create a release tag and a release commit in Git;\n1. Create a new release with release notes on GitHub;\n1. Push the changes;\n1. Comment on relevant GitHub issues and pull request.\n\n## Opinions\n\nRelease is an _opinionated_ tool, which means it intentionally implements certain behaviors that I personally like without the ability to modify them. Let's talk about some of those behaviors.\n\n### Release first, tag later\n\nUnlike other automation tools, Release makes sure to create a release commit, tag it with the appropriate tag, and push those changes to Git **only after** your release pipeline succeeded. This keeps your Git history clean and makes recovering from failed releases much easier.\n\n### Remote in sync\n\nSince the package is published before the release commit is pushed, Release verifies that the current branch is in sync with `origin` before doing anything. If the remote branch has moved on (e.g. two pull requests merged back-to-back in CI), the release is skipped and left to the pipeline run for the newer commit. If the branch has unpushed commits, the release fails.\n\n### Quality check\n\nRelease requires your package to pass the [`publint`](https://publint.dev/) check before proceeding with the publishing. This ensures that you are publshing a valid package that won't break your consumers. If you've ever misconfigured an `exports` condition, you know how neat this is.\n\n### GitHub-only\n\nRelease is written to work with projects hosted on GitHub because that is where I release my software. It relies on GitHub repository URL schemes, creates GitHub releases, crawls issue and pull request references.\n\n### Configuration-driven\n\nRelease is driven by the release configuration file. It does not use labels, tags, or other things to trigger or influence the release. It does not require a release pull request. You describe the release profiles, create an automated CI job, and get a continuous release pipeline. See the [recipes](#recipes) on how to configure and use Release in GitHub Actions.\n\n### Release commit\n\nRelease creates release commits in the `chore(release): v${NEXT_VERSION}` format. They will look like this in your Git history:\n\n```\ncommit cee5327f0c7fc9048de7a18ef7b5339acd648a98 (tag: v1.2.0)\nAuthor: GitHub Actions