You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Backwards compatibility & version negotiation #2892
Make 2026-07-28 a real version the SDK can speak alongside every prior one: per-instance version knobs, the era classifier, and per-request _meta validation on the server. This is where the stateless server-side obligations land.
What's in it
Per-instance "what versions do I serve/speak" knobs (server + client); add 2026-07-28 to the negotiable set.
Era classifier + dispatch: server reads the _meta envelope (version/clientInfo/capabilities), validates it, emits the unsupported-version / missing-capability errors with typed data, and skips the legacy init gate for modern traffic.
Era-gate everything removed from core for modern peers: ping, logging/setLevel, roots/list_changed, the tasks surface, the URL-elicitation-required error.
(no scenario passes on this alone — it's the foundation the others stand on)
Together with New HTTP serving path (modern + dual-era), Capabilities API + server/discover handler, subscriptions/listen, Context object (layered, per-request): server-stateless
Shipped in v2.0.0b1: per-instance version configuration, the era classifier with typed unsupported-version errors, era-gated core methods, and resultType stamping on modern results. The server-stateless and request-metadata conformance scenarios pass.
Activity
maxisbey commentedon Jul 1, 2026
Shipped in v2.0.0b1: per-instance version configuration, the era classifier with typed unsupported-version errors, era-gated core methods, and resultType stamping on modern results. The
server-statelessandrequest-metadataconformance scenarios pass.AI Disclaimer