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-deprecated organizations, and those in the nursery may
eventually move to
rust-lang while those in deprecated would appreciate an
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-nurseryorganization 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-langvia an accepted RFC or to
rust-lang-deprecated/another owner at a point decided by the library subteam.
- An RFC for movement to
rust-langis 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.
- Future significant changes to the library require an RFC.
- Crates in
rust-langare advertised as “core Rust” packages.
- Some crates may eventually move into
stditself, at which point the library subteam will call an FCP after which the library will be folded in if accepted.
- If a
rust-langcrate becomes stale over time, an RFC is written to move it to the
If you’ve got any questions, please feel free to consult the RFC itself, or just ask questions here!
Given that background, here’s a summary of where all current
are now located:
These crates will continue to live in
rust-lang-deprecated for a few reasons
- 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.
urlin 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!
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.
This change is largely intended to message clearly what crates are “getting
ready for stabilization” and which are “in need of dire overhaul”. It’s highly
likely for crates like
time to move from the deprecated area to the nursery
after receiving some API scrutinization, for example.