doc: mention key removal in rpc interface modification
What the developer wrote
Authored by rkrux
doc: mention key removal in rpc interface modification
A discussion in a previous PR 32618 prompted me to add this note.
What changed, and why it matters
This commit is a one-line documentation edit. It adds 'removing a key from an object' to the list of backward-incompatible RPC interface changes in the developer notes. There is no code change, no bug fix, and no security impact.
No action required. This is a documentation-only change with no security relevance.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit modifies doc/developer-notes.md to clarify that removing a key from an RPC response object is a backward-incompatible change. It is purely a documentation/development-guideline update with no functional changes to Bitcoin Core.
Changed components
doc/developer-notes.mdInspect captured patch +1 / −1
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index c7c8fe13..0d7ec137 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -1426,7 +1426,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
A few guidelines for modifying existing RPC interfaces:
-- It's preferable to avoid changing an RPC in a backward-incompatible manner, but in that case, add an associated `-deprecatedrpc=` option to retain previous RPC behavior during the deprecation period. Backward-incompatible changes include: data type changes (e.g. from `{"warnings":""}` to `{"warnings":[]}`, changing a value from a string to a number, etc.), logical meaning changes of a value, or key name changes (e.g. `{"warning":""}` to `{"warnings":""}`). Adding a key to an object is generally considered backward-compatible. Include a release note that refers the user to the RPC help for details of feature deprecation and re-enabling previous behavior. [Example RPC help](https://github.com/bitcoin/bitcoin/blob/94f0adcc/src/rpc/blockchain.cpp#L1316-L1323).
+- It's preferable to avoid changing an RPC in a backward-incompatible manner, but in that case, add an associated `-deprecatedrpc=` option to retain previous RPC behavior during the deprecation period. Backward-incompatible changes include: data type changes (e.g. from `{"warnings":""}` to `{"warnings":[]}`, changing a value from a string to a number, etc.), logical meaning changes of a value, key name changes (e.g. `{"warning":""}` to `{"warnings":""}`), or removing a key from an object. Adding a key to an object is generally considered backward-compatible. Include a release note that refers the user to the RPC help for details of feature deprecation and re-enabling previous behavior. [Example RPC help](https://github.com/bitcoin/bitcoin/blob/94f0adcc/src/rpc/blockchain.cpp#L1316-L1323).
- *Rationale*: Changes in RPC JSON structure can break downstream application compatibility. Implementation of `deprecatedrpc` provides a grace period for downstream applications to migrate. Release notes provide notification to downstream users.
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.