The bip324 library is attempting to be as flexible as possible, imposing the least amount of requirements on the caller. Sometimes this goal can seemingly be at odds with itself. For instance, we want to maintain a relatively low MSRV, but also support relatively new async frameworks like tokio.
1.39 to now - Rust 1.70
1.30 to 1.38 - Rust 1.63
1.27 to 1.29 - Rust 1.56
1.17 to 1.26 - Rust 1.49
1.15 to 1.16 - Rust 1.46
1.0 to 1.14 - Rust 1.45
Tokio versions to their MSRVs.
This means that the library’s minimum tokio version needs to be under 1.39 in order to satisfy its MSRV requirement. Anything above that would effectively raise bip324’s MSRV to whatever tokio’s is at that version. Bip324 could force an MSRV compliant version by setting a maximum tokio version. This adds a requirement for the caller to use an older tokio version, but is this worth it? What is the benefit to the caller? The goal for the bip324 library is to be flexible for the caller, “I can run on anything!”. But it shouldn’t force the caller to run older versions. If the caller has a higher MSRV and a more recent tokio requirement, bip324 shouldn’t care.
The bip324 has well-scoped usage of tokio, only depending on the stable I/O traits AsyncRead, AsyncReadExt, AsyncWrite, AsyncWriteExt. It’s able to use a wide range of tokio versions, so we set the constraint to a super general 1. This means, anything in the major version of 1. It is up to the caller now to actually choose which specific version is bundled with their executable. The bip324 library could go the extra step though and try to test some tokio versions to give the caller confidence it will work with theirs. Ideally, every single major version is tested, but that is a bit unsustainable and probably very noisy even for the caller. Think of the combination matrix if you have more than a handful of dependencies and you want to be very thorough. But what about the window from version 1.0.0, the first version of this major version, and whatever the highest publish version is, say 1.42.0. While not definitive, if both those extremes work I’d have confidence there is a high chance everything in between does as well.
Cargo has a helpful minimal-versions flag (still in the unstable -Z set which means only available on the nightly channel) which creates a lockfile with all the minimum versions possible. Although it looks like direct-minimal-versions might be recommended over it. But the idea is this can test the “floor” dependency set of a library. And if using the “v2” version resolver of cargo, the default behavior is the grab the maximum versions. So the “ceiling” set can be tested as well. In both these scenarios, any version constraints of the library are still enforced. The “v3” resolver is neat because it also takes into account the MSRV of a library or application. This is a new set of dependencies since some will be capped compared to the all out max set produced by the v2 resolver. This MSRV-compatible set is still helpful for a library developer as a sanity check, yes, given my dependency constraints there does actually exist a set of versions which works with my MSRV. It also allows maintainers to easily build the library with the MSRV compiler, ensuring that it does in fact meet the MSRV (“this code can be built with this version of rust”). But the v3 resolver limits the testing “window” of versions (lowers the ceiling) which a caller might end up using. Ideally, the v2 max versions are still tested, so that there is still a large window of versions. And we are in luck, cargo has a ignore-rust-version flag which effectively lets us use the v2 resolver. One could create 3 different lockfiles for these cases and check them in for each commit. This gives a historical paper trail. But it might be enough for some, depending on there thoroughness appetite, to only check-in the MSRV one and generate the min/max versions on the fly.
In bip324’s case, tokio is hidden behind a feature flag so that non-async callers don’t have to add this large dependency to their tree. This is a standard pattern, but there are also some scenarios where enabling a feature flag will bump the effective MSRV of a library. What if a library has a constraint where it must use a new version of tokio? For example, bip324 needed some new special tokio feature in order to use it. This complicates testing what an MSRV is of a library, since the feature flag matrix could get hairy, but doesn’t seem like a deal breaker as long as it is made clear to callers in documentation.
This work is marked with
CC0 1.0
