From caf364b19e85abb22b7bb4b56e56be86f6cb55f6 Mon Sep 17 00:00:00 2001 From: Will Jones Date: Mon, 17 Nov 2025 12:05:46 -0800 Subject: [PATCH 1/2] ci: add critical fix section to release notes --- .github/release.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.github/release.yml b/.github/release.yml index b90688c5ef6..a246b34cf11 100644 --- a/.github/release.yml +++ b/.github/release.yml @@ -7,6 +7,9 @@ changelog: - title: Breaking Changes 🛠 labels: - breaking-change + - title: Critical Fixes ‼️ + labels: + - critical-fix - title: New Features 🎉 labels: - enhancement From 26e3e9ca85a2f066ad68b46d9567fa8b9b128018 Mon Sep 17 00:00:00 2001 From: Will Jones Date: Mon, 17 Nov 2025 12:22:08 -0800 Subject: [PATCH 2/2] add guidance --- CONTRIBUTING.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d3f3ac1cc63..cf332215e49 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -48,6 +48,37 @@ Our Rust benchmarks are run multiple times a day and the history can be found [h Separately, we have vector index benchmarks that test against the sift1m dataset, as well as benchmarks for tpch. These live under `benchmarks`. +## Reviewing issues and pull requests + +Please consider the following when reviewing code contributions. + +### Rust API design +* Design public APIs so they can be evolved easily in the future without breaking + changes. Often this means using builder patterns or options structs instead of + long argument lists. +* For public APIs, prefer inputs that use `Into` or `AsRef` traits to allow + more flexible inputs. For example, use `name: Into` instead of `name: String`, + so we don't have to write `func("my_string".to_string())`. + +### Testing +* Ensure all new public APIs have documentation and examples. +* Ensure that all bugfixes and features have corresponding tests. **We do not merge + code without tests.** + +### Important Labels + +There are two important labels to apply to relevant issues and PRs: + +1. `breaking-change`: Any PR that introduces a breaking change to the public API + (Rust or Python) must be labelled as such. This is used to determine how to + bump the version number when releasing. You can still add this label even + after merging a PR. +2. `critical-fix`: Any PR that fixes a critical bug (e.g., security issue, data + corruption, crash) should be labelled as such. These are bugs that users might + have without realizing. Fixes that aren't critical include bugs that return + an error message. These labels are used to determine whether a patch release + is needed. + ## Code of Conduct We follow the Code of Conduct of [Python Foundation](https://www.python.org/psf/conduct/) and