-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Upgrade rustls to 0.20 #1505
Upgrade rustls to 0.20 #1505
Conversation
If you rebase it should fix the MySQL build failure. |
b6857d2
to
624f289
Compare
This should be ready to be merged |
Is there a chance of at least having this PR merged in a separated branch? Rustls 0.20 was released in September last year |
FWIW I have a branch with all of my PRs merged. I only test it on postgres though. https://github.com/paolobarbolini/sqlx/tree/merged-0.6.0 |
I wouldn't mind having a 0.6.0 alpha or something so I wouldn't have to maintain a git dependency |
Thank you very much @paolobarbolini |
@paolobarbolini if you restore the removed Feel free to mark it |
It would still be a breaking change wouldn't it? |
Ugh, yeah. I really doubt anyone is using it either way. It'd violate the spirit of semver, but is the breakage justified when you consider the importance of keeping RusTLS up to date? In my mind, it's on the same level of breakage as accidentally reintroducing the damn At the end of the day, the impl in question probably shouldn't have been part of the public API in the first place, as it was only meant for use internally. |
It'd be really stupid, but we could theoretically keep |
We could, but then when rustls and webpki upgrade to ring 0.17 we'll still be on 0.16 because of webpki 0.21. I'm thinking that we could silently make the breaking change and see how it goes. sqlx doesn't return any webpki types from the public API, so it'd be hard to find someone calling the impl. |
The idea is that we'd upgrade to Or I could just stop whinging and kick out a 0.6.0 just for this. There's a part of me that really doesn't like that idea though. I think it's just because I feel like a backwards-incompatible release should have some meat to it to justify the upgrade. I guess there's a few other backwards-incompatible public dependency upgrades we could roll in and treat it as more of an incremental release. |
It think the dependency upgrades plus the Rust 1.60 dependencies features thing would be a great excuse to make a 0.6 release. Rust 1.60 comes out in two months though, so we'll still have some time to see if there's anything else we can put in this release. |
What's the current plan here? Would be nice to get this out so I don't have to keep building duplicate rustls stacks. |
In the process replaces async-rustls, which hasn't been updated yet, with futures-rustls.