Skip to content

Warn on implicit stdio initialization#338

Open
atesgoral wants to merge 1 commit into
modelcontextprotocol:mainfrom
atesgoral:warn-stdio-implicit-connect
Open

Warn on implicit stdio initialization#338
atesgoral wants to merge 1 commit into
modelcontextprotocol:mainfrom
atesgoral:warn-stdio-implicit-connect

Conversation

@atesgoral
Copy link
Copy Markdown
Contributor

Summary

Implements phase 2 of #334 after the 0.15.0 release.

  • Emit a deprecation warning when MCP::Client::Stdio#send_request performs the compatibility implicit initialization path.
  • Keep the existing implicit initialization behavior for this release step.
  • Cover the warning path and the explicit MCP::Client#connect no-warning path.
  • Add an Unreleased changelog entry.

How Has This Been Tested?

  • dev test -- 847 runs, 2159 assertions, 0 failures

Notes

dev style currently reports existing unrelated Minitest/AssertEmptyLiteral offenses in files outside this change. No new offense is reported for the touched files.

@koic
Copy link
Copy Markdown
Member

koic commented May 8, 2026

Thanks for the follow-up. Since v0.15.0 was just released, wait a bit before merging and releasing.

@atesgoral atesgoral force-pushed the warn-stdio-implicit-connect branch from 7c0d146 to b6462fe Compare May 23, 2026 16:07
@atesgoral
Copy link
Copy Markdown
Contributor Author

@koic Shall we get this in now?

@koic
Copy link
Copy Markdown
Member

koic commented May 24, 2026

The timing for merging and releasing this Phase 2 is a bit of a balancing act, but the idea was to merge it after roughly a month had passed since the release of https://github.com/modelcontextprotocol/ruby-sdk/releases/tag/v0.15.0, which already included Phase 1.

At the same time, delaying it too long would reduce the chance for existing users to become aware of the transition, so it probably makes sense to merge it fairly soon.

On the other hand, the final behavior change in Phase 3 will be a breaking change, so it may be better to leave a reasonably long gap after Phase 2 before shipping that one (perhaps around three months?).

In any case, it probably makes sense to include this in the next release. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants