search

quinn-rs / quinn

Async-friendly QUIC implementation in Rust
Apache License 2.0
3.85k stars 394 forks source link

0.10 release planning #1528

Closed djc closed 1 year ago

djc commented 1 year ago

Time to start talking about the next semver-incompatible release, I guess?

We definitely want to wait for:

Other things to consider:

Should we consider bumping the next version to 1.0? Our API has been pretty stable...

mxinden commented 1 year ago

Should we try to get https://github.com/quinn-rs/quinn/pull/1219 in?

That would be wonderful! :pray:

Ralith commented 1 year ago

I'd like to include mechanics for enabling MTUD automatically where supported (some sort of PlatformConfig?), since most users won't and shouldn't need to bother with target-specific configuration.

How do we plan for QUIC V2?

IIRC QUIC V2 is mainly an anti-ossification measure that won't impact public API. It'd be healthy for us to have it but I don't think it's pressing. Might bear a double-check.

Should we consider bumping the next version to 1.0?

I agree we're getting close, but if we're going to treat 1.0 as special we should probably defer a decision until we've actually not broken for a good while. Alternatively, we could abandon cosmetic concerns and just start bumping the major version without a care.

mxinden commented 1 year ago

How do we plan for QUIC V2?

IIRC QUIC V2 is mainly an anti-ossification measure that won't impact public API. It'd be healthy for us to have it but I don't think it's pressing. Might bear a double-check.

Correct, see:

This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.

Note that "version 2" is an informal name for this proposal that indicates it is the second standards-track QUIC version. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risk.

https://datatracker.ietf.org/doc/draft-ietf-quic-v2/

abonander commented 1 year ago

Should we consider bumping the next version to 1.0?

As long as rustls is part of the public API, I wouldn't recommend that.

Ralith commented 1 year ago

Should we try to get https://github.com/quinn-rs/quinn/pull/1219 in?

As much as I'd love to get this merged finally, it doesn't need to be a blocker since it's not API-breaking, and can easily be included in a patch release. If it continues to be a difficult review it probably shouldn't delay the other more practically beneficial changes we have staged.

djc commented 1 year ago

We should probably get #1529 in before release. I think that's probably the only thing blocking the release at this point?

Ralith commented 1 year ago

I think so; I should be able to review that within the next few days.

XOR-op commented 1 year ago

Since #1529 has been merged, should we plan to release 0.10? It looks like all the checkpoints have been resolved.

djc commented 1 year ago

We should review #1545 and #1547 before we decide to release. I think those will be relatively straightforward, though.

djc commented 1 year ago

Draft changelog:

Documentation

Internal improvements

Ralith commented 1 year ago

Rename min_guaranteed_mtu to min_mtu for clarity

This is a bit confusing as a literal changelog entry because in 0.9 the parameter was called initial_max_udp_payload_size.

udp: add safe wrapper for setsockopt()

This is purely internal.

LGTM otherwise!

djc commented 1 year ago

It's done! https://github.com/quinn-rs/quinn/releases/tag/0.10.0