obi1kenobi / cargo-semver-checks

cargo-semver-checks Lint your crate API changes for semver violations. • Quick Start • FAQ • Configuration • Troubleshooting • Contributing Quick Start Or use as a GitHub Action (used in in this repo): Each failing check references specific items in the Cargo SemVer reference or other reference pages, as appropriate. It also includes the item name and file location that are the cause of the problem, as well as a link to the implementation of that query in the current version of the tool. FAQ • What Rust versions does support? • Can I use with Rust? • What if my project needs stronger guarantees around supported Rust versions? • Does the crate I'm checking have to be published on crates.io? • Git repository detection and configuration • Use with jujutsu • What features does enable in the tested crates? • My crate uses conditional compilation. Can scan it? • Should I run for multiple target triples? • Does have false positives? • Will catch every semver violation? • Can I configure individual lints? • If I really want a new feature to be implemented, can I sponsor its development? • How is similar to and different from other tools? • Why is it sometimes and ? • What is the MSRV policy with respect to semver? What Rust versions does support? uses the rustdoc tool to analyze the crate's API. Rustdoc's JSON output format isn't stable, and can have breaking changes in new Rust versions. When each version is released, it will at minimum include support for the then-current stable and beta Rust versions. It may, but is not guaranteed to, additionally support some nightly Rust versions. The GitHub Action by default uses the most recent versions of both and stable Rust, so it should be unaffected. Users using in other ways are encouraged to update when updating Rust versions to ensure continued compatibility. Can I use with Rust? Support for Rust versions is on a best-effort basis. It will work _often, but not always_. If you _must_ use , it's strongly recommended to pin to a specific version to avoid broken workflows. relies on the rustdoc JSON format, which is unstable and changes often. After a new rustdoc JSON format version gets shipped in , it usually takes several days to several weeks for it to be supported in a new , during which time it is not possible to use with those versions. It's also possible that support for some versions may be dropped even while older stable versions are still supported. This usually happens when a rustdoc format gets superseded by a newer version before becoming part of any stable Rust. In that case, we may drop support for that format to conserve maintenance bandwidth and speed up compile times. For example, v0.24 supported rustdoc formats v24, v26, and v27, but did not support the nightly-only v25 format. What if my project needs stronger guarantees around supported Rust versions? If you'd like extended support for older Rust versions, or an SLA on supporting new releases, we're happy to offer those _on a commercial basis_. It could be in the form of a formal support contract, or something as simple as discussing expectations over email and setting up a recurring GitHub sponsorship for an agreed-upon amount. Please reach out at the email in the Cargo.toml and let us know about what projects this is for and what their needs are. Does the crate I'm checking have to be published on crates.io? No, it does not have to be published anywhere. You'll just need to use a flag to help locate the version to use as a baseline for semver-checking. By default, uses crates.io to look up the previous version of the crate, which is used as the baseline for semver-checking the current version of the crate. The following flags can be used to explicitly specify a baseline instead: Custom registries are not currently supported (#160), so crates published on registries other than crates.io should use one of the other approaches of generating the baseline. Git repository detection and configuration When looking up a git revision with , will walk up the current directory until it finds a directory to resolve the revision and extract the corresponding worktree. You can use the following environment variables to influence git repository detection: • [ ]: explicitly set the location of the directory. If the value is a relative path, it is resolved from the current working directory. If this is not set, will search the current working directory and any of its parents for the directory. • [ ]: a colon ( ) separated list of absolute paths which should not search for the directory. This can be used to prevent from searching slow network mounted directories. This environment variable cannot be used to prevent searching the current working directory, or a directory explicitly set with [ ]. If this is not set, will search the current working directory and any of its parents (up to the root directory). • [ ]: enable git repository detection across filesystems. By default, will not cross filesystem boundaries when searching for the directory. Set this environment variable to to enable cross-filesystem detection. This environment variable has no effect when setting [ ] explicitly. [ ]: https://git-scm.com/docs/git.html#Documentation/git.txt-codeGITDIRcode [ ]: https://git-scm.com/docs/git.html#Documentation/git.txt-codeGITCEILINGDIRECTORIEScode [ ]: https://git-scm.com/docs/git.html#Documentation/git.txt-codeGITDISCOVERYACROSSFILESYSTEMcode Use with jujutsu Setting the environment variable allows using with a non-colocated jujutsu repository. What features does enable in the tested crates? By default, checking is done on all features except features named , , , , or ones with prefix , , or , as such names are commonly used for private or unstable features. This behaviour can be overriden. Checked feature set can be changed to: • _all_ the features, selected with , • only the crate's default features, selected with , • empty set, selected with . Additio…