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

0.10 release planning #1528

Closed
3 tasks done
djc opened this issue Apr 4, 2023 · 12 comments
Closed
3 tasks done

0.10 release planning #1528

djc opened this issue Apr 4, 2023 · 12 comments

Comments

@djc
Copy link
Member

djc commented Apr 4, 2023

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

We definitely want to wait for:

Other things to consider:

  • Should we try to get Unify connection and endpoint drivers #1219 in?
  • How do we plan for QUIC V2? (It seems to be sitting in some late part of the IETF review queue, with seemingly all the reviews done. Does this impact our public API?)

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

@mxinden
Copy link
Collaborator

mxinden commented Apr 4, 2023

Should we try to get #1219 in?

That would be wonderful! 🙏

@Ralith
Copy link
Collaborator

Ralith commented Apr 5, 2023

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
Copy link
Collaborator

mxinden commented Apr 7, 2023

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
Copy link
Contributor

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
Copy link
Collaborator

Ralith commented Apr 19, 2023

Should we try to get #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
Copy link
Member Author

djc commented Apr 19, 2023

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

@Ralith
Copy link
Collaborator

Ralith commented Apr 19, 2023

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

@XOR-op
Copy link
Contributor

XOR-op commented May 4, 2023

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

@djc
Copy link
Member Author

djc commented May 4, 2023

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

@djc
Copy link
Member Author

djc commented May 8, 2023

Draft changelog:

Documentation

Internal improvements

@Ralith
Copy link
Collaborator

Ralith commented May 8, 2023

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
Copy link
Member Author

djc commented May 11, 2023

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

@djc djc closed this as completed May 11, 2023
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

5 participants