From b5e521c4a187aaf2602ebea5897b8c15fcf0483e Mon Sep 17 00:00:00 2001 From: Brendan Clement Date: Fri, 29 May 2026 12:41:30 -0700 Subject: [PATCH] docs: add cross-SDK parity guidance for code review --- REVIEW.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 REVIEW.md diff --git a/REVIEW.md b/REVIEW.md new file mode 100644 index 000000000..65aab71c6 --- /dev/null +++ b/REVIEW.md @@ -0,0 +1,26 @@ +# Code review guidelines + +Repo-specific guidance for automated PR reviews. + +## Cross-SDK parity + +LanceDB exposes the same core (`rust/lancedb`) through Python, TypeScript (`nodejs`), +and Java bindings. Behavioral drift between SDKs is a recurring problem, so watch for +parity gaps when reviewing — but only flag real ones: + +* If the change adds or modifies user-facing API or behavior in the shared core + (`rust/lancedb`), check whether each binding that should expose it (`python`, + `nodejs`) does. A core change with no corresponding binding update is worth a note. +* If the change adds or modifies a public API in one SDK but not the other, open the + sibling SDK's corresponding module and state whether an equivalent exists. If not, + note it as a possible parity gap and suggest a follow-up issue. +* For bug fixes, first read the sibling SDK's analogous code path to check whether the + same bug exists there. Only raise parity if it actually does. Do not ask to "port" a + fix for a bug that only ever existed in one binding. +* Stay silent on internal-only refactors, tests, docs, and changes with no cross-SDK + surface. +* Parity expectations apply to the Python and TypeScript (`nodejs`) SDKs. Java currently + implements only the remote table, not the local/embedded backend, so it is expected to + be partial — do not flag Java for missing local-only functionality. +* Keep parity feedback to a short, clearly-labeled note (e.g. "Possible SDK parity + gap: …"). It is advisory, not a merge blocker.