Smooth the renaming transition of `wasm32-wasi`

[alexcrichton]

Proposal

In a previous MCP it
was approved to rename today's wasm32-wasi target to wasm32-wasi-preview1.
The proposal for doing this however was to be a mostly "cold turkey" rename. The
fallout of this is that users of the wasm32-wasi target would likely
experience breakage with most build infrastructure needing an update. The goal
of this proposal is to make this a bit less of a "cold turkey" transition and
give a larger window for users to update.

Note: This proposal does not intend to re-litigate the motivation for the
original MCP. The intent is only to smooth the transition to the desired
end-state with hopefully less hypothetical confusion along the way.

Currently there are a number of pull requests from Yosh related to renaming the
wasm32-wasi target:

• rust-lang/rust tracking issue
• rust-lang/rust
• blog post
• rust-lang/rustc-dev-guide
• rust-lang/stdarch

These PRs have not yet been merged primarily because Yosh ran out of time to
spend on them. He's asked me and I've agree to help push these over the finish
line. In reviewing them, however, I shared concerns that some folks brought up
on the rust-lang/rust PR about the breakage this might cause. Virtually all
users of the wasm32-wasi target will experience breakage from this rename for
example because build scripts, Cargo invocations, artifact directories, etc, all
need to change. This sort of transition can also be a bit messy with breakage
landing on nightly affecting some users but not those users using stable. The
goal of this proposal is to smooth this transition over a period of time to
reduce the amount of immediate breakage. The sum of work required is basically
the same where everyone will still need to update, but there will be a window to
update rather than a requirement at a particular point in time.

Specifically this proposal is to have the following schedule and plan for
renaming the wasm32-wasi target.

1. Implement a wasm32-wasi-preview1 target in the Rust compiler alongside the pre-existing wasm32-wasi target.
2. Ship the wasm32-wasi-preview1 target via Rustup as a Tier 2 target, enabling usage on nightly Rust and eventually stable.
3. Let the above ride the Rust release channels to stable.
4. After one stable release implement a warning when wasm32-wasi is used that the target has been renamed to wasm32-wasi-preview1.
5. After the change from (4) reaches stable and has been there for one release, remove the wasm32-wasi target and the warning from (4).

To users this rollout will first appear in a stable release that supports both the old and the new target names. Projects can immediately start transitioning and any form of stable/beta/nightly testing will all continue to work. Three releases later stable users will start getting warnings about the wasm32-wasi target being renamed, and three releases after that the target will be removed. Projects spanning stable/beta/nightly will have a one-release window to make changes.

In a tabular form based on Rust releases the above schedule would look like:

Rust Stable	Rust Beta	Rust Nightly	Notes
N - 2	N - 1	N	add support for wasm32-wasi-preview1 (1, 2)
N - 1	N	N + 1
N	N + 1	N + 2
N + 1	N + 2	N + 3	warn on wasm32-wasi (4)
N + 2	N + 3	N + 4
N + 3	N + 4	N + 5
N + 4	N + 5	N + 6	remove wasm32-wasi (5)
N + 5	N + 6	N + 7
N + 6	N + 7	N + 8	wasm32-wasi is now gone on all release channels

Note that this proposal additionally differs from the steps in the tracking issue where no work will be done on either Rustup or Cargo, instead keeping all the changes here isolated to just rustc.

Mentors or Reviewers

I plan on being on the hook for the implementation work here. I'd help take over the renaming PRs from Yosh. I'd update the renaming PR to not remove wasm32-wasi just yet but instead build both that and the new target. Additionally I'd implement the warning for using wasm32-wasi and the eventual removal of the wasm32-wasi target. If I disappear or become unresponsive I would expect that at any time the Rust project could remove the wasm32-wasi target and warning if it's present.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip
stream for that. Use this issue to leave procedural comments, such as
volunteering to review, indicating that you second the proposal (or third, etc),
or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[Noratrieb]

The rename was approved already. This transition period looks very reasonable, making sure that stable and nightly can be used consistently seems important.
@rustbot second