The rules
1
Major version = breaking wire change
The major version (
RCP/N) increments only on a breaking wire change.
RCP/1 is the current, stable major.2
Additive changes stay within a major
New optional methods, capability keys, fields, and
_meta are added within
a major version and discovered via capabilities —
never a version bump.3
Negotiation is lifetime-stable
The version negotiated at
initialize governs a
session for its whole lifetime. A peer supports the contiguous range
[1 .. protocolVersion]; the negotiated version is min(client, server).Why a single integer
TheprotocolVersion is one integer, not a semver string — the same choice MCP
and ACP make. It identifies a set of guarantees, and finer-grained feature
detection is what capabilities are for. This keeps
negotiation trivial: take the min, done.
Because RCP/1 is the floor, a server returns
-32002 (VersionMismatch) only
if it supports no version ≥ 1. In practice the negotiated version is always
≥ 1.What this means for you
Server authors
Add features by advertising new capabilities. Never break an existing
request/response shape within RCP/1 — add, don’t change.
Client authors
Gate on
supports(...), not on the version string. A newer server is safe to
talk to; you simply won’t use capabilities you don’t recognise.Experimental surface that shouldn’t wait for a spec revision goes through the
x-<vendor> extension space — no version bump, no
central coordination.