[ about | methodology | contributing ]

Build reports

C*

M*

R*

a*

b*

c*

d*

e*

f*

g*

h*

i*

j*

k*

l*

m*

n*

o*

p*

q*

r*

s*

t*

u*

v*

w*

x*

y*

z*

About

This is a tiny* project to map what you get when you try to compile given versions of given crates against given rustc versions.

The Objective is to properly map out some sense of practical MSRV to consider when trying to yourself declare a MSRV, and pick dependencies based on MSRV support, and/or, trying to find version combinations that "work" when building an arbitrary crate on an arbitray rust target.

It is in no way comprehensive, and is just a minimal best effort strategy to narrow down your problem quickly.

Methodology

The approach I've used is so simple, it could be called "rudimentary".

For each rustc, and for each crate version, construct a dummy project layout that depends on an exact version of that, and see if it compiles

# $tmpdir/Cargo.toml
[package]
name = "test"
version = "0.1.0"
authors = ["Kent Fredric <kentnl@gentoo.org>"]

[dependencies.CRATENAME]
version = "=VERSION"
# $tmpdir/src/lib.rs
# *empty file*

Note that it doesn't even think about features, and if there are second-order dependencies that just happen to get pulled in, and happen to themselves be broken, then this scenario reports a false negative.

It also reports false negatives when dependencies don't strictly follow semver, and break API, leading to compile failures (and also when dependencies are not sufficiently semver-binding).

It is also somewhat subject to passes being eventually downgraded to failures, if the version of the dependency used in the test worked at the time, but a future version breaks either MSRV or API and otherwise circumvents semver bindings.

It is in some casess possible to work around these situations through careful package selection, and some data about that somewhere is also on a whishlist for when I have some clue how to do such a thing.

Notedly, these risks are why I've prioritized getting coverage of fundamental crates, particularly, ones with either few, or no dependencies, or at least, recursively checking the dependencies themselves.

Contributing

See bugs in the information? Got crates you think should be covered but arent? Something else? Feel free to Open an issue over on the repository over at https://github.com/kentfredric/rust-vmatrix/.

Just be aware, at the time of this writing there is a sizeable backlog of 1071 crates amassing 1007930 build combinations which works out at a cool range of between 172.92 days ( 4149.98 hours ( 248998.95 minutes ( 14939937 seconds ) ) ) and 1.92 years ( 699.95 days ( 16798.83 hours ( 1007930.00 minutes ( 60475800 seconds ) ) ) ) of build time queued.

Crates with few versions and crates with few dependencies are prioritized as these are the ones that tend to be more indiciative of the overall ecosystems MSRV.