Good evening rustlers! Today the libs subteam has implemented RFC 1242 which changes where a number of the rust-lang crates are located, and to ensure that the word gets out I’d like to summarize what happened here.

tl;dr; Crates are now found in the new rust-lang-nursery and rust-lang-deprecated organizations, and those in the nursery may eventually move to rust-lang while those in deprecated would appreciate an active maintainer!

RFC 1242 Recap

The main purpose of RFC 1242 was to detail an explicit plan for grown a larger set of ‘official’ libraries outside of std as well as set forth a path to move large sets of functionality into the standard library itself. The large number of crates that are currently in rust-lang are a bit of a mishmash of high to low quality in varying degrees of upkeep. In order to organize this, a vision was spelled out for how crates become an “official” crate of the rust-lang organization. The life cycle looks like:

Crates first enter the rust-lang-nursery organization as “0.X.Y” crates.

This represents no major commitment on behalf of rust-lang but rather simply a “trial period”.

The original author of the crate maintains control, approving PRs, editing code, etc.

The broader community is encouraged to participate in development and crates in the nursery are more broadly advertised.

At some point, crates in the nursery either move to rust-lang via an accepted RFC or to rust-lang-deprecated /another owner at a point decided by the library subteam.

An RFC for movement to rust-lang is required as it signifies that ownership is being transferred to the community, and buy in is important. Additionally, diving into API design and rationale is always useful!

is required as it signifies that ownership is being transferred to the community, and buy in is important. Additionally, diving into API design and rationale is always useful! Once in rust-lang , the crate is then owned by the Rust community at large, and major changes are governed by the library subteam in consultation with the original maintainers.

, the crate is then owned by the Rust community at large, and major changes are governed by the library subteam in consultation with the original maintainers. Future significant changes to the library require an RFC.

Crates in rust-lang are advertised as “core Rust” packages.

Some crates may eventually move into std itself, at which point the library subteam will call an FCP after which the library will be folded in if accepted. If a rust-lang crate becomes stale over time, an RFC is written to move it to the rust-lang-deprecated organization.

If you’ve got any questions, please feel free to consult the RFC itself, or just ask questions here!

Existing Crates

Given that background, here’s a summary of where all current rust-lang crates are now located:

Nursery Crates

bitflags

getopts

glob

libc

log

rand

regex

rustc-serialize

tempdir

uuid

Deprecated Crates

These crates will continue to live in rust-lang-deprecated for a few reasons such as:

Niche functionality that doesn’t necessarily justify being an “official rust-lang crate”.

The crate is already deprecated in favor of another implementation (e.g. url in favor of rust-url ).

in favor of ). The API of the crate is in such need of an overhaul that it needs to radically change to be considered to move back into the nursery. This isn’t an indication that the functionality itself is deprecated, simply that it’s being messaged that it needs to be overhauled.

If you’d like to become the maintainer the library subteam is more than willing to transfer ownership to you!

fourcc

hexfloat

num

rlibc

semver

term

threadpool

time

url

What does this mean for me?

In short, this doesn’t actually mean much for the consumers of these crates. All crates will retain the same name on crates.io, and the crates aren’t tagged as "nursery" or “deprecated”, so the compiler won’t be issuing warnings or anything about usage of any of these crates.