Rust 2018: the home stretch

With the first Edition Preview out last week, it’s time to firm up plans for completing Rust 2018! This post lays out some ideas on how to do that.

Proposed milestones

Based on our current trajectory, I propose we target the 1.30 release on 2018-10-25 for announcing Rust 2018 to the world. That target, based on team discussions, is feasible, but it also leaves room for an additional release cycle within 2018 if necessary.

There are a lot of moving parts (and teams!) involved in this release, so it’s difficult to keep the whole thing organized. To help keep us on track for the release, I propose that we set out the following three milestones, aligned to the release cycle:

  • 2018-08-02: Edition preview 2
  • 2018-09-13: Edition release candidate (RC)
  • 2018-10-25: Edition release :tada:

The meaning of these milestones varies by area. I’ve broken things down into three major areas, below.

Toolchain

Covers everything distributed by rustup, i.e. the work of the Lang, Libs, Tools, and Docs teams.

Work on the toolchain has a tighter deadline than work elsewhere, due to our strict six-week release cycle. At a high level, that means:

  • Preview 2: feature-complete across the board (rustc, cargo, rustfix, rustfmt, rls, clippy, docs) on nightly; not all features will be stable yet. Everything we intend to ship in Rust 2018 must be reliably working, but may be lacking in polish. The migration experience should be solid. Seek widespread feedback on the toolchain at this point.

  • RC: the toolchain should be ready to ship, as-is, as Rust 2018. There will only be very limited scope for backports that would go into the release itself, i.e. the 1.30 will go into beta at this milestone.

  • Release: the final product! Includes only low-risk, high-priority fixes after the RC.

The release team should weigh in on the precise way we want to handle the train system to actually produce the final release. (cc @Mark_Simulacrum)

Domain use-cases

Covers the four ares of use targeted for 2018, i.e. the domain WGs.

  • Preview 2: WG should have consensus on what will ship for the 2018 release. Crates should be in roughly beta status, but may still have some serious gaps. Docs should be in at least rough draft status.

  • RC: Crates should be feature complete and fully at beta quality or better. Docs should be usable as-is, but may have significant room for improvement prior to release. Seek widespread feedback at this point.

  • Release: Crates and docs fully polished and published.

Website and marketing

Covers design and content of the website, as well as coordination with tech press, marketing, and community teams.

  • Preview 2: Website style guide complete. Website implementation and content in rough “beta” status: plausible, but clear room for improvement. Content team formed. Core marketing materials (slogans, tight pitches) complete. Accessory marketing materials (press release, etc) in rough draft. Seek internal team feedback at this point.

  • RC: All web site and marketing materials in full release candidate stage, i.e. plausible to ship as-is. Seek widespread feedback at this point.

  • Release: Highly polished version of RC artifacts.

Project management

Even the above high-level description is daunting; trying to collect granular to-do items for all of the above in a single list is unworkable.

What I suggest instead is that each team create GitHub milestones (or some equivalent) corresponding to the three milestones above, for each high-level item, and then link to it centrally. That will make it easy for anyone to see where things are.

To help surface issues and prioritize, I think we should have a ~weekly chat meeting on the edition planning channel. In contrast with the “standup” meetings we were holding earlier this year, doing this over text should make it easier for folks to only participate in the relevant parts; I envision essentially walking through and triaging the milestones each time. After each meeting, we’d produce a brief writeup of the status and post it here on internals, to make it easy for people to keep up.

More generally, I envision project management work being shared by all of the relevant team leads, including the release team; those are the folks I’d expect to attend triage, but the meeting would be held in the open so that anyone can help out.

Team leads: I’d like to get an OK from you explicitly on this thread, and in particular that you understand and are game for the high-level milestones and tracking work described here. In particular:

36 Likes

Sounds good to me! Let’s :shipit:

3 Likes

yup! this is exactly as we’ve discussed and should be doable :slight_smile:

Sounds good to me! We might need to revisit the exact list of tools that we’re going to include, but there will definitely be some!

I agree that this plan looks feasible.

+1

Sounds good to me!

:+1: from the embedded WG

Looks and sounds great to me!

1 Like

Two days before my birthday, perfect! :smile_cat:

5 Likes

JFYI @Mark_Simulacrum, @aturon and I had a quick conversation on Discord where we agreed it probably makes sense for all teams to share the following milestones:

and then to use labels to distinguish different teams.

(If you’d prefer to use a per-team milestone, you still can.)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.