-
Notifications
You must be signed in to change notification settings - Fork 438
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.25 Release #2206
Comments
I noticed that we now also depend on h3, so I started a PR for upgrading h3-quinn to Quinn 0.11 already. |
Draft PR for the TLS upates in #2217. |
the |
@AaronKutch they should! If you want to help out with that, it would be greatly appreciated! |
Could I update several crates to only specify the minor version instead of patch version, when their repos indicate stricter MSRV guarantees (the last time a lot of them had their MSRV updated, it was to 1.56 because of syn 2)? E.x. most of the things that aren't async runtimes and ssl related stuff. |
I'm not sure what you mean? We don't want to pin dependencies for MSRV reasons -- we just keep the versions in |
In the workspace .toml, there are dependencies that specify down to the patch version, is that what pinning versions too specifically would mean? In most crates, the MSRV is only updated across minor version changes at most, with a few exceptions like the |
I think you're misunderstanding how Cargo manifest dependency specifications work. In Cargo, dependencies without an explicit operator work like they have an implicit So as far as I can tell from a quick glance, the only dependency where we're actually lagging is prefix-trie, which has recently had a 0.4.0 (and 0.4.1) release which we should pick up. |
I think I have been misunderstanding how cargo updates versions this whole time. I always thought the way it worked was that if there were an array of x.y.z versions and "x" was specified, then cargo was allowed to update the y and z. If "x.y" was specified, then it could only update the z. Finally, if "x.y.z" were specified then it would fix it to that exact version. I did not realize it could jump to just any SemVer compatible version, I thought that was what the modifiers like |
Most of those are taken care of in #2217, though. |
I want to start tracking what we need for the next release. I'm thinking it might be a good idea to start releasing some alphas, as I think we're waiting on a few upstream things. Thoughts?
ring
quinn
... others
The text was updated successfully, but these errors were encountered: