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
Publishing to crates.io #125
Comments
I'll note that reqwest also wants this (as some kind of prerelease) so they can get an experimental h3 setup going. |
@eagr @Ruben2424 @stammw @camshaft I'm curious to hear from any of you about how we should start publishing the crate. Publishing to crates.io will help other early adopters try it out, such as unblocking reqwest experimental usage. At the same time, it's my opinion that proper expectations of this crate should be made. The purpose of this crate is to strictly implement what is necessary for HTTP/3, without including all the batteries, so that others can mold it into their system (such as hyper). So, the public API is certainly less stable. Especially when we notice things like #145, questioning the traits. That said, I do suspect that publishing some versions and then getting things like reqwest or tower-h3 using it will help give valuable feedback that the API probably does need to change, and possibly quicker than normal. I also imagine that release a 0.1 is likely worthy of a nice blog post and celebration. All of that to ask, should it just be tagged 0.1 nowish, announce, and then likely quickly tag a 0.2? Or should we tag something even more unstable than 0.1, so that 0.1 can be a little more stable? It's likely not something to spend too much time debating, but at the same time, likely worth a small discussion instead of just shooting from the hip. |
I would wait with the 0.1 until h3 supports quinn 0.9. A more unstable tag than 0.1 until quinn 0.9 is supported sounds good to me. |
I'd be fine with publishing a |
I agree with @Ruben2424 that 0.1 could wait until we have resolved the quic trait issues. Maybe just do a 0.0.1 quickly to unblock stuff? |
We may need to use async trait to support quinn 0.9, that would greatly change the interface. |
I just saw that we accept the unidirectional encoder and decoder qpack streams in the And we also do not create these streams. The qpack spec says:
But also allows the option to avoid creating them?
So I think the dynamic table encoding and decoding does not work right now, right? |
Correct, we don't currently use the dynamic table, but as you've noticed in the spec, it's not required. It's strictly an optimization, allowing headers that aren't in the static table to be compressed. So I don't think it would block us. |
This comment was marked as off-topic.
This comment was marked as off-topic.
So, I'm thinking that within the next couple days, we just publish the crate as-is (on master) as v0.0.1. It doesn't go with a big blog post or anything, it's simply to allow a few experimenters to move forward (such as the reqwest PR). That we might change the API drastically, or need to upgrade to quinn v0.9, etc is fine as 0.0.2. Basically, the implementation is ready-ish enough, the API is close. (If any of the collaborators would like to be part of the |
What exactly do you mean with "be part of the cargo publish process"? |
Basically, do the actual release/publish process (together in chat or something), to spread the knowledge/responsibility. (Probably should document it anyways...) |
I'm open to opportunities to get involved |
It is now published 🚀 |
Hello,
I'm using h3 and h3-quinn in a reverse proxy I'd like to publish someday.
I'd like to have the h3 crates uploaded to crates.io.
I'm not sure if a proper release is waiting for #34 / #82 (found via #70), but I'd be happy even if the upload has a -pre in the version number. Someone else has uploaded forked versions (https://lib.rs/crates/httproxide-h3, https://lib.rs/crates/httproxide-h3-quinn) with possible changes (
.cargo_vcs_info.json
points to private commits), and it would be better to be able to use something tagged from this repository.Tangentially related, license information is missing in h3-quinn/Cargo.toml.
The text was updated successfully, but these errors were encountered: