Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async-HTTP not explicit on upper range of protocol-http2, breaking compatibility #196

Open
broksonic21 opened this issue Dec 18, 2024 · 1 comment

Comments

@broksonic21
Copy link

We were running async-http 0.70.0 (as a transitive dependency of async-http-faraday - we didn't have async-http explicitly, hence why dependabot didn't provide an update note for us - we typically only do dependabot updates for Gemfile packages, not transitive ones).

Note: async-http-faraday is open-ended in terms of being compatible with higher version minor versions for it's async-http dependency ( see https://github.com/socketry/async-http-faraday/blob/main/async-http-faraday.gemspec#L28 ).

That version depends on protocol-http2 via "~> 0.18" as per https://rubygems.org/gems/async-http/versions/0.70.0

Issue is we then updated protocol-http2 for other reasons (a different gem bumped it's requirement on it transitively) to 0.22.0, which broke async-http due to:

While the async-http gem followed suit in v0.85.0 #192, the older version allowed this mismatch due to its open-ended dependency on protocol-http2. (We have since fixed the issue in our code base by also bumping async-http).

Given that async-http at newer versions is still openended:

spec.add_dependency "protocol-http2", "~> 0.22"
this could easily happen again

Can async-http be more explicit on the higher end on what dependency versions it supports to avoid transitive updates breaking it in future?

@ioquatix
Copy link
Member

I am sorry this caused a problem for you.

I used to depend on specific versions, but compatibility has been pretty good for several years now.

We could go back to that model (e.g. ~> 0.22.0) but I think that may be the last major breaking change before we hit a 1.x release... which I hope will not require any further breaking changes like this.

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

No branches or pull requests

2 participants