Run make verify before opening a pull request. It runs the project's formatting, lint, test, and documentation checks, and never modifies your worktree, so what you reviewed is what you submit.
make fix is the mutating counterpart: it applies Clippy fixes, typo fixes, and formatting.
Beyond rustfmt, OpenRaft follows the conventions in CLAUDE.md. The essentials are:
- Trait bounds use
whereclauses, never inline bounds:fn f<T>() where T: RaftLeaderId, notfn f<T: RaftLeaderId>(). This applies to functions, structs, enums,implblocks, and traits. - Each file has one main trait or type and its implementations. Do not reorganize existing files unless the change requires it.
- Public API changes include a
#[since(version = "...", change = "...")]attribute that describes the change.
Public documentation lives in Rustdoc comments under openraft/src/docs/ and is published on docs.rs. Update it when a public API or user-facing behavior changes.
- Write commit messages as concise notes to collaborators. The git commit format guide is a useful reference.
- Before opening a pull request, rebase and squash your branch onto the latest
maininto one or two logical commits. - Do not rebase a published pull request. Merge
maininto it instead.
AI tools can help draft a change, but you own every submitted line.
- Understand each change well enough to defend it in review.
- Simplify generated output. Remove redundant wrappers, unnecessary abstractions, and comments that repeat the code or claim behavior it does not have.
- Match the surrounding code and this guide.
PRs that read as unreviewed AI output will be sent back for a cleanup pass before review.
make verifypasses.- The
[workspace.package]version in the rootCargo.tomland every siblingpathdependency that pins it are updated. Use a priorchore: bump versioncommit as the complete reference. - After release CI finishes, open the release page, update the release notes, and publish.