Here's the top 200 crates built against the beta channel


After turning on feature gating, I pushed a new build to the beta channel and tested the top 200 crates against it. The good news is that 10 entire crates built successfully. A lot did not, because they are declaring unstable features. We’ve got seven weeks to get as many of these lifted up to stable Rust as we can in order to make the best impression on all the 1.0 newbies.

Toolchain report for beta-2015-03-26

  • 10 successes / 196 failures

Failures, sorted by popularity

Successes, sorted by popularity


One caveat, there are likely a number of failures that are the fault of the tool I’m using, which doesn’t account for certain things yet (like ensuring the correct native libs are available). The ones we care about mostly are feature-gating failures.


And here’s the beta compared to the nightly. 71 crates are reported as ‘fixed’, meaning that they don’t work on beta but do work on nightly. Those 71 crates are almost certainly failing on beta because of feature gates.


Is this running cargo build or is it running cargo test?


I wonder how many of these are due to things like rustc-serialize, a common dependency, not being ready…


Ya, it seems regex is failing because log is failing. Otherwise, I updated regex to stable Rust tge other night. :slight_smile:


Besides any dependencies failing, I just posted the unstable APIs that are currently being used by hyper.


The lastest commit in log fixes the one problem it has; if I pull from Git, I can build it successfully. Someone (cc @alexcrichton, @huon, @sfackler) just needs to version-bump it and release it. That should help make a good deal of progress; it has 61 reverse dependencies.

I’ve submitted a pull request that should fix rustc-serialize, by reverting use of the convert feature until that’s ready. That should help make even more progress, rustc-serialize has 125 reverse dependencies.


So, I looked into the next most popular crate that’s failing, gcc (and which shows up in a lot of those failures), and it is using as_ref and from more extensively. Is it planned to stabilize convert before beta? If so, it’s probably better to just do that, and then see how much improvement you get in this list; otherwise, it’ll be a lot of work to remove all usage of convert, and then add it all back again once it lands without the gate.


@lambda I have similar thoughts. Working around an unstable convert looks quite difficult.


@huon it runs build then test.

Testing published crates is tricky because cargo may not have packaged all the scaffolding necessary for more complex scenarios. Haven’t investigated yet.


@steveklabnik oh some of my report formats pull out the root failures but not these. Would be a good addition


Here they are with root failures split out.

Toolchain report for beta-2015-03-26

  • 10 successes / 196 failures
  • 51 root failures / 141 non-root failures

Root failures, sorted by popularity

Non-root failures, sorted by popularity

Successes, sorted by popularity


Is there going to be some sort of flag or badge on indicating which build a crate is targeting (as well as each of it’s deps)?


It would be great if every single crate would have three builds, stable, beta and nightly.

These could be organized by using branches in their repos (cargo uses git also, which would make everything relatively easy).

A flag on would also be great.

Some more thoughts on that can be found here.


It would be great if the build status was somehow monitored, or at least tested in regular intervals.


We generally encouarage people to do this, but don’t enforce it.

We do this at least once a release cycle, and often more, with crater. see threads like