New release

[DemiMarie]

This blocks libp2p-quic.

[est31]

👍 a release with rustls 0.18 would be really great for mimas as well. I think at this point one needs to branch off master because of the export_keyring_material feature.

[djc]

I've filed rustls/rustls#407 about getting a rustls release.

[dvc94ch]

I think that's done now, are there any other blocking issues?

[djc]

Our interop crate depends on hyper-0.13, which relies on tokio-0.2 (as does the rest of Quinn, for now); the hyper-rustls release that supports rustls-0.19 only supports tokio 0.3.

[inodentry]

So there will be no new release until quinn migrates to tokio 0.3?

So, currently, to use quinn in my project, i need to depend on tokio 0.2 and rustls 0.17, correct?

[djc]

I think that summarizes the current status, yes. Unless you know you need something that's not part of the 0.6.1 release, I'd probably just use that.

[inodentry]

What is holding up the progress on this front? I looked at #872 and #873 but it is unclear to me what the status is (and seems like there hasn't been any update in over a month).

[djc]

I haven't been able to prioritize #873. Additionally, there seems to be some doubt about whether there'll even be a hyper release targeting tokio 0.3, so I'm waiting that out for a little bit (see #hyper on the tokio Discord).

[dvc94ch]

You actually don't need to depend on tokio, async-io would be enough (I can open a PR for this on thursday). It also works with all executors. For the hyper dependency in the interop tests, it should be fine to use hyper from git, as it's only for testing, so it doesn't really need to be published on crates.io

[inodentry]

Can I use tokio 0.3 with quinn 0.6.1, though? (by doing what you are describing)

If I want tokio, do I have to stick with 0.2?

[dvc94ch]

You can use it with any executor, as opposed to only with Tokio 0.2

[inodentry]

So that includes tokio 0.3?

[djc]

I think you're talking past each other.

quinn 0.6.1 does not support tokio 0.3, and never will.

@jamadazi if you're going to stick to quinn-proto, we could potentially cut a release for that separately, since it won't have to rely on tokio at all.

@dvc94ch I'm not convinced async-io is the right solution for us, and a change like that should probably be discussed at a design level first, in a separate issue.

[djc]

(If we're going to chat back and forth, let's do it on Gitter/Matrix, not in the issue tracker.)

[inodentry]

@djc thank you for clarifying. That's what I wanted to understand. Sounds like I'll stick with tokio 0.2.

I want to use quinn with tokio for my server, and quinn-proto without tokio for my client. So I am interested in using tokio.

I prefer to use the latest versions of my dependencies when possible, so I wanted to know if tokio 0.3 was an option. It was not clear from the wording @dvc94ch used, and I don't want to potentially waste hours of my time trying tokio 0.3 if it's not going to work. Sorry for spamming the issue tracker.

I would prefer to use the same version of quinn/quinn-proto on both sides, so don't feel like you have to make a separate release of quinn-proto because of me. I don't need it.

[DemiMarie]

My recommendation would be to use quinn-proto git HEAD, tbh.

[quentusrex]

I didn't see this issue or thread before I started on a branch to update to the newly released tokio 1.0: https://github.com/quentusrex/quinn/tree/deps_update_tokio_1.0

[djc]

#873 now contains upgrades to Tokio 1.0 (including bytes 1.0) and rustls 0.19 (et al). This mostly compiles except for one method that's gone missing on mio's UdpSocket (see the PR description -- maybe we can get around the macOS compatibility issue there) and the tests fail because I botched some changes required for bytes 1.0.

[djc]

Now that #873 has been merged, we'll want to fix #968 and potentially get in fixes for #981 and #984 as well. Any contributions welcome!

[inodentry]

#981 and #984

These seem like they shouldn't be blocking the release? Aren't they just perf optimizations that could come in a patch release afterwards?

It would be nice to have a release supporting the latest tokio and rustls sooner.

[djc]

That's why the "potentially". One or two more days shouldn't really matter much at this point.

[djc]

(Also, some of the optimizations will likely require API changes, so it'd be good to get those in.)

[bochaco]

Any news on when a new release with tokio v1 is planned?

[djc]

I need to wrap up #1003 -- sorry for the delay, it's been very busy.

[bochaco]

ah no worries, thanks a lot for replying, just to know, we are looking forward to it 👍

[djc]

First draft of 0.7 release notes: https://gist.github.com/djc/0d49f8564246f6a16edbcb4b50e111b9. Let me know if you have feedback.

[djc]

We have released 0.7.0! Thanks for your patience everyone.

[bochaco]

Thanks a lot for the notification @djc !!