
Collection of primitives for SSI libraries and applications.
Development
See CONTRIBUTING.md for how to set up, test and submit changes. To report a vulnerability, see SECURITY.md.
Release
Releases are automated with release-plz and follow Cargo's SemVer rules. Versions are never bumped by hand.
- On every push to
main, release-plz opens or updates a release pull request (chore: release vX.Y.Z, labelledrelease). It contains the next version inCargo.tomlandCargo.lockand a newCHANGELOG.mdentry, both derived from the Conventional Commits onmainsince the last release.cargo-semver-checksmakes sure an API-breaking change can't go out as a compatible version. - A maintainer reviews the version and changelog. To adjust them, commit to the release branch shortly before merging, since release-plz regenerates the pull request whenever
mainchanges. - Approving and merging the release pull request publishes the crate to crates.io, then tags the commit as
vX.Y.Zand creates a GitHub release with the same changelog.
Before 1.0, a breaking change (feat!:, fix!: or one detected by cargo-semver-checks) bumps the minor version (0.1.3 → 0.2.0), and anything else bumps the patch version (0.1.3 → 0.1.4).
Only commits that matter to users of the crate appear in the changelog: ci, test, style and chore commits are left out, except dependency updates (chore(deps)).
The rules are configured in release-plz.toml.
The release workflow runs without long-lived publishing credentials:
- crates.io accepts the upload through trusted publishing, only from
release-plz.ymlrunning in thereleaseenvironment, which is limited tomain. - The release pull request, tags and GitHub releases are created by the
impierce-release-plzGitHub App, so CI runs on the release pull request like on any other. The App's credentials are stored in the repository variableRELEASE_PLZ_CLIENT_IDand the secretRELEASE_PLZ_PRIVATE_KEY.