Chuyển tới nội dung chính

Pull request process

  1. Open an issue first for anything larger than a fix, so the design can be agreed before code is written.
  2. Branch from main and keep the change focused. One concern per PR.
  3. Run the checks locally: cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings, and cargo test --workspace against Postgres. CI runs the same gate.
  4. Document the change. Every PR that changes behavior adds:
    • a changelog entry describing what changed for users;
    • a migration note when users must change config, code, or data;
    • updated docs, in the same PR, for any public API or behavior change.
  5. Describe the PR: what changed, why, how it was tested, and any follow-ups.
  6. Review: at least one maintainer approval. Architecture changes (new crate edges, new public traits, wire-format changes) need a maintainer from the owning area.
  7. Merge with squash, using a conventional title (feat:, fix:, docs:, refactor:, …).

Breaking changes are allowed before 1.0 but must ship with a migration note.