# release-plz: Rust Release Pull Requests and Crate Publishing > release-plz turns Conventional Commits and detected API changes into a maintained release Pull Request, then publishes the resulting Rust crate and creates a hosted release. It suits Rust workspaces that want repeatable registry and Git hosting workflows from CI or the CLI. **release-plz/release-plz** — Publish Rust crates from CI with a Release PR. - Repository: https://github.com/release-plz/release-plz - Website: https://release-plz.dev - Stars: 1,506 · Forks: 195 - Language: Rust - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/release-plz-release-plz ## Why release-plz Changes the Rust Release Sequence release-plz addresses the repetitive coordination between source changes, package versions, registry publication, Git tags, and hosted release notes. It is aimed at maintainers of Rust packages, especially repositories where releasing several workspace crates would otherwise require repeated manual edits and commands. The central review artifact is a Release PR, not an unreviewed publish action. The release decision is based on git history following Conventional Commits and API breaking changes detected by cargo-semver-checks. That distinction matters. A commit message can imply the intended version change, while a public API comparison can reveal a breaking change that needs a version response. The project then updates package versions in Cargo.toml and generates changelog content with git-cliff. Once the Release PR is merged, the documented workflow creates a tag named `-v`, runs `cargo publish`, and creates a GitHub, Gitea, or GitLab release based on that tag. This gives maintainers one visible approval point before the publication sequence proceeds. The README also says release-plz keeps the Release PR current as more commits are merged, which makes it more than a one-time release generator. ## Registry Comparison Instead of Tag-Only Version Selection release-plz makes a design choice that separates it from release-please: it compares local packages with versions published in the Cargo registry. According to the README, release-please determines the next version from git tags, while release-plz uses the registry as the comparison point. That approach is tailored to crates whose distribution state matters, including unpublished local versions and releases that may have occurred outside the current repository workflow. The default publication target is `crates.io`, but the project also supports GitHub, Gitea, and GitLab for repository actions. The CLI is documented as usable from a terminal or other CI systems, while the GitHub Action can perform both updating and releasing from CI. This gives the project two operating modes without changing its basic release model. There is a practical consequence. Release-plz is primarily a Rust packaging tool, not a language-neutral release service. Its Rust-specific checks include Cargo package metadata and cargo-semver-checks, and its publish action is `cargo publish`. A repository that does not use Cargo may gain little from the registry comparison even if it could adopt Conventional Commits elsewhere. ## A First Release Workflow Through the Release PR The README directs users to the documentation at `https://release-plz.dev/` for installation and configuration details. It does not provide a complete installation command or a minimal workflow file. The documented first choice is between the GitHub Action and the CLI. For a GitHub-based repository, the GitHub Action is the path described for running release-plz from CI. Its role is to update packages with a Release PR and later release them. For Gitea, GitLab, a terminal, or another CI system, the CLI is the relevant path. The documentation does not specify a required flag, token name, environment variable, or minimal configuration, so those values should be taken from the official usage documentation. The first real use is therefore operational rather than a code sample. Add release-plz through one of those documented entry points, allow it to inspect commits and API changes, and review the generated Release PR. Check the changed Cargo.toml versions, changelog, and package set before merging. After the merge, confirm that the expected `-v` tag exists, that `cargo publish` succeeds for the intended crate, and that the corresponding hosted release was created. ## Workspace Scope and Release Metadata Are the Main Constraints The repository is a Rust workspace whose members are declared as `crates/*`, and the workspace uses edition 2024. This confirms that release-plz is designed with multi-crate Rust repositories in mind, but it does not mean that every workspace has identical release needs. Dependency ordering, crate-specific versions, package publishing rules, and whether all crates should be published together still need to be handled by the repository's configuration and workflow. The README lists version bumps in Cargo.toml, changelog generation, hosted release creation, and Cargo registry publishing as separate supported functions. Those functions can fail independently. A version change may be generated without a publishable package, a publish may be rejected by the registry, or a hosted release may be affected by repository permissions. The documentation does not describe retry behavior or a rollback procedure, so maintainers should inspect CI logs and release state rather than assume that a failed stage is automatically repaired. The project also uses git-cliff and cargo-semver-checks as parts of its decision process. This makes commit quality and the accuracy of the public API matter. A malformed Conventional Commit can produce an unhelpful version signal, while an API change that is not represented in the detected package surface may require maintainer review. Release-plz reduces mechanical work, but it does not replace release policy decisions. ## Cargo-Specific Automation Versus Manual Release Control cargo-smart-release is listed as a similar project, and the distinction is concrete. The README describes it as focusing on workspace crate releases and providing manually crafted changelogs. release-plz instead centers its workflow on a maintained Release PR, Conventional Commit history, API breaking-change detection, and publishing through Cargo's release path. A maintainer who wants a single version bump to trigger a publish should compare those workflows directly rather than choosing based on a general idea of release automation. cargo-release and cargo-workspaces are also credited as sources of inspiration, but the README does not claim that release-plz reproduces their feature sets. The relevant comparison is architectural. release-plz separates review from release: maintainers inspect and merge a PR, then CI handles tags, registry publication, and hosted release records. A direct CLI release command gives more immediate control but places more responsibility on the person or surrounding script for sequencing those operations. This distinction becomes important for private registries. The README explicitly names `crates.io` as the default cargo registry, but the available text does not document a complete private-registry configuration or describe authentication requirements. The presence of Cargo tooling in the workspace does not confirm that an arbitrary registry setup is supported without additional configuration. ## Maintenance, Licensing, and Upgrade Surface The repository is not archived. Its last push was on 2026-10-15, and the listed releases include `release-plz-v0.3.172` on 2026-10-12, `release-plz-v0.3.171` on 2026-10-10, and `release-plz-v0.3.170` on 2026-10-07. Those dates indicate recent repository activity. They do not by themselves establish compatibility with a particular configuration, registry, or CI provider, so version upgrades should be checked against the release notes and configuration schema. The repository's Cargo.toml declares `license = "MIT OR Apache-2.0"`, and the README states that the project is licensed under the Apache License, Version 2.0 or the MIT license at the user's option. This is a source-code licensing statement for the project. It does not answer questions about a user's registry account, hosted repository terms, or the licensing of dependencies, and this review does not provide legal advice. The repository also contains `release-plz.toml`, a `.schema/` directory, tests, and a Dockerfile. Based on that layout, release-plz is not just a single shell wrapper around `cargo publish`. It is a Rust workspace with configuration validation, tests, and container packaging. Those components add maintenance surface, but they also provide concrete files to inspect when changing release behavior. ## Conclusion Adopt release-plz when a Rust repository already follows Conventional Commits and wants a reviewable release PR as the approval gate. Do not choose it without first checking how it handles private registries, nonstandard commit messages, workspace dependencies, and credentials. The first practical verification is whether its generated Release PR reflects the intended versions and changelog before it is merged. ## FAQ ### What does release-plz do for Rust packages? It creates or updates a Release PR based on Conventional Commits and API breaking changes detected by cargo-semver-checks. After that PR is merged, it can create a Git tag, publish the crate with `cargo publish`, and create a GitHub, Gitea, or GitLab release. ### How does release-plz choose the next version? The README says release-plz compares local packages with versions published in the Cargo registry. It uses git history and API breaking-change information to produce the Release PR. ### Can release-plz run outside GitHub Actions? Yes. The README documents a CLI for use from a terminal or other CI systems, including Gitea and GitLab support. The README does not provide the complete installation command or required authentication configuration. ## Sources - [License: Apache-2.0](https://github.com/release-plz/release-plz/blob/main/LICENSE) - [Project website](https://release-plz.dev) - [README](https://github.com/release-plz/release-plz/blob/main/README.md) - [release-plz/release-plz on GitHub](https://github.com/release-plz/release-plz) - [Releases](https://github.com/release-plz/release-plz/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/release-plz-release-plz