[adr] BiDi is an implementation mechanism, not a public API#17670
[adr] BiDi is an implementation mechanism, not a public API#17670titusfortner wants to merge 3 commits into
Conversation
Code Review by Qodo
1. Option 3 ambiguous
|
PR Summary by QodoAdd ADR process docs and record BiDi as internal implementation detail WalkthroughsDescription• Add an ADR/decision-record process, template, and approval rules under docs/decisions. • Record the decision that BiDi is internal and must not appear in supported public APIs. • Add a decisions index to make adopted proposals discoverable and citable. Diagramgraph TD
A([Contributor]) --> F[["docs/decisions/"]] --> B["ADR template"] --> C["BiDi ADR 0001"] --> D["Index"] --> E["Process README"]
subgraph Legend
direction LR
_p([Person]) ~~~ _dir[["Directory"]] ~~~ _doc["Document"]
end
High-Level AssessmentThe following are alternative approaches to this PR: 1. Use GitHub Discussions/Issues as the canonical decision log
2. Adopt an ADR tool/convention (e.g., adr-tools) with CLI automation
Recommendation: The current approach (plain Markdown ADRs with a lightweight documented process and a simple index) is the best fit here: it keeps the decision record close to the codebase, is language/tool neutral, and is easy for all binding maintainers to follow without introducing new tooling dependencies. File ChangesDocumentation (4)
|
|
Code review by qodo was updated up to the latest commit 3d21495 |
🔗 Related Issues
ADR process itself depends on #17665 merging
Decision
BiDi is an implementation mechanism, not a public API. New capabilities are exposed as
high-level, protocol-neutral APIs, idiomatic per language, subject to our standard
deprecation policy. Everything in a BiDi namespace is internal: still reachable for
anything not yet wrapped, but not documented and subject to change without warning.
A binding conforms when:
Considered options