chore(quic): prepare v0.9.0-alpha

[mxinden]

Description

Notes & open questions

@kpp @thomaseizinger any objections?

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[dariusc93]

I am excited to see how this performs compared to the previous implementation, although shouldnt it be 0.9.0-alpha.0 instead?

[thomaseizinger]

I am excited to see how this performs compared to the previous implementation, although shouldnt it be 0.9.0-alpha.0 instead?

See https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#dealing-with-alphas.

[thomaseizinger]

I am excited to see how this performs compared to the previous implementation, although shouldnt it be 0.9.0-alpha.0 instead?

See master/docs/release.md#dealing-with-alphas.

One could argue that this change is non-breaking but given that it is essentially a re-write, I think it is better to release it as a breaking change to make the update an explicit yet effortless action.

[thomaseizinger]

No objection. What is the plan forward for removing the alpha status of QUIC?

[mxinden]

I am excited to see how this performs compared to the previous implementation, although shouldnt it be 0.9.0-alpha.0 instead?

Numbers on https://observablehq.com/@libp2p-workspace/performance-dashboard look very promising (see rust-libp2p-quinn) @dariusc93.

[mxinden]

What is the plan forward for removing the alpha status of QUIC?

We have multiple outstanding bugs:

• fix(quic): improve listener socket selection when dialing #4259
• quic: ability to listen on ipv4 and v6 #4165
• quic: implement stateless resets #3419

I would have to give the above bugs a bit more thought. Though I am leaning towards releasing v0.9.0 (without -alpha), in case no major bugs are found in v0.9.0-alpha.

[mxinden]

Tagged and published.