Skip to content

CompatHelper: bump compat for HTTP to 2, (keep existing compat) - #36

Closed
github-actions[bot] wants to merge 1 commit into
mainfrom
compathelper/new_version/2026-05-29-00-23-43-158-04109242378
Closed

CompatHelper: bump compat for HTTP to 2, (keep existing compat)#36
github-actions[bot] wants to merge 1 commit into
mainfrom
compathelper/new_version/2026-05-29-00-23-43-158-04109242378

Conversation

@github-actions

Copy link
Copy Markdown

This pull request changes the compat entry for the HTTP package from 1 to 1, 2.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

@kalidke
kalidke force-pushed the compathelper/new_version/2026-05-29-00-23-43-158-04109242378 branch from bae066c to c686bc6 Compare May 29, 2026 00:23
@kalidke

kalidke commented Jun 5, 2026

Copy link
Copy Markdown
Member

Triaged 2026-06-05. This is not a drop-in compat bump — HTTP.jl 2.0 is a breaking API change. CI fails across all Julia versions with:

MethodError: no method matching serve!(::handler, ::String, ::Int64; stream::Bool)
@ ModelContextProtocol src/transports/http.jl:561

HTTP.jl 2.0 changed the HTTP.serve! signature (and likely other Request/Response/streaming APIs the transport relies on). HTTP 1.x remains fully supported and is the resolved version today.

Holding this until a dedicated HTTP 2 migration PR updates src/transports/http.jl and re-verifies the full HTTP + SSE suite against HTTP 2. Not merging the bare compat widening, since it would let the resolver pick a broken HTTP 2.

@kalidke

kalidke commented Jul 30, 2026

Copy link
Copy Markdown
Member

Closing as stale rather than merging.

This has been open since May, is now CONFLICTING, and its CI failures predate the 0.6.0 release — so its checks say nothing about current main, which has since moved through #65, #68 and #70.

HTTP.jl 2 is also not something we want to pull in speculatively: the standing plan is to adopt it only when something actually requires it (it sits in the breaking-change cluster for being breaking, not for being needed). When that day comes, CompatHelper will raise a fresh PR against a current base, which is strictly better than rebasing this one.

No objection to the change itself — just no reason to carry it open in the meantime.

@kalidke kalidke closed this Jul 30, 2026
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.

1 participant