Each release of Rust we’ve typically got at least a few new APIs that are being stabilized in the standard library. This has historically been done by the libs team but is also a great opportunity wanting to help out! I’ll detail the process here and see if we can help start bringing in some new contributors.
All APIs in the standard library start their life marked as
#[unstable] and tagged with a tracking issue. For example
TcpStream::connect_timeout is unstable right now and points to #43079 as a tracking issue. Notably you’ll also find the
B-unstable tags on all tracking issues for unstable APIs in the standard library.
Next up in the lifecycle of an unstable API a member of the libs team will propose stabilization and once all libs members have checked their checkboxes the issue is tagged with
final-comment-period meaning it’s ready for stabilization. As a side note, anyone can ask for a libs member to propose stabilization!
Next up comes the fun part. For example right now we have a few issues that are all in
final-comment-period, which you can typically see through this GitHub query. The second an issue goes into FCP it’s ready for a “stabilization PR” which tends to look like this, namely:
#[unstable] tag is changed to
#[stable] with an appropriate version listed
- The PR/commit message mentions
Closes #xxx to close out the tracking issue once it’s landed
- Various test code and crates using the feature have their
#![feature] directives deleted
And that’s it! Often times we don’t have a PR-per-issue-in-final-comment-period like the
mem::discriminant PR listed above, but instead there’s a batch PR for all current final-comment-period issues with a commit-per-issue. Either way is fine!
Now timing-wise ideally what would happen is that as soon as all issues enter
final-comment-period we’d get a PR to stabilize the issue and we’d land it via bors. Typically that doesn’t happen, so we instead shoot for a PR just before the end of a cycle to stabilize all current
final-comment-period issues (a batch PR). Typically though even that doesn’t happen so we often just after the beta branches make a batch PR to the master branch and then backport it to the beta branch.
This is where you can help! For the upcoming 1.21 release we haven’t yet landed the batch of stabilizations that we’ll want for the release. The
mem::discriminant PR is an example of one that we’ll be backporting (as we should have landed it before beta branched), but there’s a few more final-comment-period issues! If you’re interested in helping out here please let us know! A member of the libs team will try to post to this thread when a cycle is just around the corner as a reminder to go through
final-comment-period issues and stabilize them as well.