[Doc] Align the ROADMAP deprecation wording with the shipped behavior - #526
Open
koic wants to merge 1 commit into
Open
[Doc] Align the ROADMAP deprecation wording with the shipped behavior#526koic wants to merge 1 commit into
koic wants to merge 1 commit into
Conversation
## Motivation and Context The Deprecated Features paragraph still described the pre-modelcontextprotocol#516 design, claiming the SDK "emits deprecation warnings when they are used with protocol version 2026-07-28 or newer". Since modelcontextprotocol#516 the only deprecation warning is the client-side one, emitted on a modern connect that declares the Roots or Sampling capabilities, exactly as the 1.2.0 CHANGELOG entry states. Logging never warns (`notify_log_message` is the sanctioned SEP-2575 delivery path on that wire), and the server never warns either: `initialize` counter-offers a legacy version, a modern `Configuration` pin is rejected at construction, and the modern lifecycle refuses the deprecated server-to-client request APIs outright rather than serving them with a warning. The paragraph now describes the shipped behavior and says where each feature lives per lifecycle: unchanged on legacy, carried on 2026-07-28 by input requests embedded in `InputRequiredResult` responses (the SEP-2322 multi round-trip requests pattern) and the envelope's `logLevel`. Those carriers are not the SEP-2577 replacements: the spec's deprecated-features registry points migrating implementations outside the protocol (tool parameters or configuration, direct LLM provider APIs, stderr or OpenTelemetry), and the paragraph now says so instead of presenting the modern delivery forms as the replacements. ## How Has This Been Tested? Documentation-only change; proofread against the `ProtocolDeprecations` module header and the CHANGELOG entry that shipped this behavior in 1.2.0, which the 1.3.0 release leaves unchanged.
atesgoral
approved these changes
Aug 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
The Deprecated Features paragraph still described the pre-#516 design, claiming the SDK "emits deprecation warnings when they are used with protocol version 2026-07-28 or newer". Since #516 the only deprecation warning is the client-side one, emitted on a modern connect that declares the Roots or Sampling capabilities, exactly as the 1.2.0 CHANGELOG entry states. Logging never warns (
notify_log_messageis the sanctioned SEP-2575 delivery path on that wire), and the server never warns either:initializecounter-offers a legacy version, a modernConfigurationpin is rejected at construction, and the modern lifecycle refuses the deprecated server-to-client request APIs outright rather than serving them with a warning. The paragraph now describes the shipped behavior and says where each feature lives per lifecycle: unchanged on legacy, carried on 2026-07-28 by input requests embedded inInputRequiredResultresponses (the SEP-2322 multi round-trip requests pattern) and the envelope'slogLevel. Those carriers are not the SEP-2577 replacements: the spec's deprecated-features registry points migrating implementations outside the protocol (tool parameters or configuration, direct LLM provider APIs, stderr or OpenTelemetry), and the paragraph now says so instead of presenting the modern delivery forms as the replacements.How Has This Been Tested?
Documentation-only change; proofread against the
ProtocolDeprecationsmodule header and the CHANGELOG entry that shipped this behavior in 1.2.0, which the 1.3.0 release leaves unchanged.Types of changes
Checklist