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!
- 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-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).
- 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.
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.
