Skip to content

Determine futures version support #1481

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

Closed
seanmonstar opened this issue Apr 7, 2018 · 5 comments
Closed

Determine futures version support #1481

seanmonstar opened this issue Apr 7, 2018 · 5 comments
Labels
B-rfc Blocked: More comments would be useful in determine next steps.
Milestone

Comments

@seanmonstar
Copy link
Member

So, with the release of futures 0.2, it was revealed that this is temporary state, and that breakage was coming again real soon. Unfortunately, 0.2 support isn't fully there in Tokio, and it sounds like the recommendation from the Futures team is to just wait till 0.3 (or libstd or whatever).

Sooooo, we kind of still need to provide futures 0.1 support. I don't know if there is value in maintaining a 0.2 support behind a feature flag. It feels horrible to revert all the work that was done, but 0.12 cannot be released as-is.

I've spent some time on futures-compat, and it does allow compiling hyper master (with 0.2 futures) against tokio with no feature flag (using 0.1 futures). However, I don't think I'd personally want to release with 0.2 wrapping tokio in compat, since there is a penalty cost of cloning notifiers.

Perhaps the best action is to revert to a public 0.1 futures API, and publish futures-compat to allow anyone that wants to explore futures 0.2 to be able to do so, but production use of hyper doesn't degrade.

@seanmonstar seanmonstar added the B-rfc Blocked: More comments would be useful in determine next steps. label Apr 7, 2018
@seanmonstar seanmonstar added this to the 0.12 milestone Apr 7, 2018
@jimmycuadra
Copy link

It is out of the question to just wait for futures 0.3 before releasing hyper 0.12?

@seanmonstar
Copy link
Member Author

That is a possibility, but otherwise 0.12 is pretty close to ready. There'd also be much less breaking changes... Well, somewhat.

The question would be how long do we wait? Continue to hold off 1) upgrade to http crate, 2) upgrade to tokio, 3) http2, 4) Send Client?

The existing APIs in 0.11 are a little confusing to use.

@scottlamb
Copy link

fwiw, I'm looking forward to the hyper 0.12.x API changes and would be sad if it were delayed for months because of this. futures 0.3 is apparently coming "relatively soon", but it will be nightly-only at first, so unsure when it's actually coming for stable.

@jimmycuadra
Copy link

Another way to look at it... Given:

  • The ecosystem is in major flux right now
  • Anyone who's paying attention knows everything is pretty unstable until Rust 2018 in September
  • futures has just set precedent for releasing a new version at the same time as announcing that its replacement is imminent

it's pretty reasonable to release an 0.12 as is. And maybe announce, similarly to futures, that an 0.13 will be coming sooner than it's been between previous versions of hyper.

@seanmonstar
Copy link
Member Author

So, 0.12 will release with futures 0.1 implementations, since 0.2 is considered unstable. Any wishing to using hyper with the unstable futures 0.2 can fairly easily combine it with the futures-compat crate.

Thanks all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-rfc Blocked: More comments would be useful in determine next steps.
Projects
None yet
Development

No branches or pull requests

3 participants