Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
60 lines (48 loc) · 2.68 KB

CONTRIBUTING.md

File metadata and controls

60 lines (48 loc) · 2.68 KB
Raw

Contributing to the Canton Rust SDK

Thanks for your interest! Issues, bug reports, and pull requests are welcome.

Development setup

  • Rust 1.88+ (the workspace MSRV; rustup toolchain install 1.88.0).
  • No system protoc needed — the build vendors one.
  • Optional, for live integration tests: a local Canton participant via cn-quickstart LocalNet.

Before you open a PR

All of these must pass (CI enforces them):

cargo fmt --all --check
cargo clippy --workspace --all-targets --all-features   # -D warnings via workspace lints
cargo test  --workspace --all-features
RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --all-features

Guidelines:

  • Tests are not optional. New behavior ships with a unit or in-process test; anything that talks to a node also gets an env-gated live test (CANTON_TEST_* variables — see the test files for the pattern).
  • No panics in library code (unwrap/expect/indexing are denied by lints outside tests).
  • Errors: map into canton_core::Error, keep the retriable classification correct, and document # Errors on public functions.
  • SemVer: public types are #[non_exhaustive] where growth is expected; builder methods use with_*/add_* naming. Generated proto types are exempt (see the stability policy in canton-proto).
  • Keep commits focused; update CHANGELOG.md under [Unreleased].
  • Architectural decisions (anything hard to reverse: crate boundaries, stability promises, wire-facing behavior) get an ADR in docs/adr/ — add a new numbered record rather than editing an old one.
  • Versioning: all canton-* crates release in lockstep with one shared version (ADR-0005). Publishing has an order and a checklist — RELEASING.md; a crates.io version cannot be taken back, and half a family published in the wrong order leaves the rest unpublishable until the next version.
  • CI actions are pinned to a commit, with the human-readable version in a trailing comment (actions/checkout@11d5960… # v4). A tag is mutable: whoever controls the action's repository can repoint v4 at anything, and it would run with our checkout and our secrets. To bump one, resolve the new tag (gh api repos/<owner>/<repo>/git/ref/tags/<tag> --jq .object.sha) and update both the SHA and the comment.

Security issues

Please do not open public issues for suspected vulnerabilities — see SECURITY.md.

License

By contributing you agree that your contributions are licensed under the Apache License 2.0, the license of this repository.