Oct 26 2022

hyper v1.0.0-rc.1

I’m thrilled to announce that the first release candidate for hyper 1.0 is now available. hyper is a protective and efficient HTTP library for all. You can try it out immediately, leave us feedback, or keep on reading to see what’s going on.

What’s all this about 1.0

At the beginning of the year, I said we’d be releasing hyper 1.0, and then shared a timeline to get it done. We started by defining a VISION. That was the destination, where we were going. Shortly thereafter, we had a ROADMAP. That was how we get there. Then, the development work began and continued throughout the summer.

We’re pulling into view of the destination. It’s just over there, on the horizon. Now’s the time to make sure everything feels good before we park in a stable spot. That’s what the Release Candidate is for!

What’s in RC1

What has changed

The CHANGELOG has a fuller list, but let me briefly explain a few bigger changes. What we used to call the “high-level” API pieces have been removed (hyper::Client and hyper::Server) from the core library. The “runtime” integration has been removed, which includes the types that used Tokio’s TcpStream, timers, and executor. We split up the Connection type to be have one per HTTP version. This is mostly to prepare for the eventual addition of HTTP/3, which will require a different IO type, but also provides performance improvements by removing a branch on every poll.

The VISION and ROADMAP include many of the reasons why. We did learn a couple things along the journey, mostly around the “unresolved questions” in the roadmap, and those appeared in specific issues containing proposals and discussion. Still, this is just a release candidate, I’ll write up much more for the full launch.

What isn’t included (yet)

Some of the things that were removed are planned to appear in hyper-util, but aren’t there quite yet. Also, a couple core features that were proposed in the ROADMAP are still being worked on, but since they’re additions, and not critical, it didn’t seem wise to block waiting on them.

What could change?

Theoretically, I suppose anything could. But it’s unlikely that there would be large changes. Still, the entire point of Release Candidates is to get feedback about whether some changes are needed before we freeze for the full release. I expect those to be small in scope. You can watch what remains to be done on the 1.0 project board. Most are additions, things that would change the API will labeled as such.

Who should try it

Please give it a try if these apply to you, and you want to help contribute.

  • Those who mostly use the “low-level” conn API, hyper::server::conn and hyper::client::conn.
  • Framework authors, such that you build a library on top of those APIs.
  • Or even if you work on applications that use those directly, instead of hyper::Client and hyper::Server.

We want your experience reports.

And who should wait?

  • If you make heavy use of hyper::Client, because of its connection pooling, a replacement isn’t yet available.
  • If you don’t have time to kick some tires and tell us what hurt, wait until we make it smoother.
  • If you use a library built on top of hyper, well you won’t need to do anything until that library does!

What will we be doing next?

We’ll be actively and passively collecting feedback. Anyone is welcome to try it out, and file issues about anything you find. You can also join us on Discord. We’ll also be approaching teams from using hyper in different ways, to make sure the “use cases” from the VISION are taken care of. What we learn from this will likely mean some more release candidate versions will be published.

We also are starting up a docs and guides push. We want a smooth, complete upgrade guide when 1.0.0 pops. Some patterns that used to be built into hyper’s core are now done with more modular pieces, involving multiple crates. So we will update and create new guides explaining how to do so.

Several of the “missing pieces” involve porting useful patterns over to the hyper-util crate. We didn’t block the first release canidate on these because they aren’t required to try out the core. But many people will certainly want several things over there!

Thanks <3

I’ve been very proud of our wonderful contributors, some who have been here for a while, and several who recently showed up. You’ve made this project the success it is, and helped get move hyper along the journey to 1.0. I’ll put together a full list of all that helped as part of the final 1.0.0 announcement. Until then, thank you all so much!

What can you do?

You can go read the CHANGELOG, or view the rendered documentation.

You can try it out in your project:

[dependencies]
# you don't need to use "full", you can enable less features if you want
hyper = { version = "1.0.0-rc.1", features = ["full"] }

Report any issues, or ask questions on Discord. Write a blog post about what you tried. Come help us write some better docs, or guides, or some of the utils.

  • #hyper
  • #rust
  • #rust-lang
  • #http