0.25 Release about trust-dns HOT 10 OPEN

I'm not sure what you mean? We don't want to pin dependencies for MSRV reasons -- we just keep the versions in Cargo.lock low enough that CI can still pass.

from trust-dns.

I noticed that we now also depend on h3, so I started a PR for upgrading h3-quinn to Quinn 0.11 already.

from trust-dns.

Draft PR for the TLS upates in #2217.

from trust-dns.

the smallvec version and some other utility crates are quite old, could they be updated if it doesn't conflict with MSRV?

from trust-dns.

@AaronKutch they should! If you want to help out with that, it would be greatly appreciated!

from trust-dns.

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.

from trust-dns.

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 backtrace crate.

from trust-dns.

I think you're misunderstanding how Cargo manifest dependency specifications work. In Cargo, dependencies without an explicit operator work like they have an implicit ^ operator, so any semver-compatible newer version can be used. Since there's not currently a smallvec 2.x version, our dependency specification is already compatible with the newest version of smallvec (and if you look at Cargo.lock you can see that we currently use 1.13.2 for testing).

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.

from trust-dns.

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 >= did. It seems like ~ does what I expected, I don't know how I never noticed this. The only crates that can actually be updated right now by changing the .toml is h3*, prefix-trie, quinn, and rustls.

from trust-dns.

Most of those are taken care of in #2217, though.

from trust-dns.