Cargo and Rustup development



Cargo is one of the most important tools in the Rust ecosystem. It has been around since before Rust 1.0 and over that time has had a lot of features added. However, there has not been much long-term planning done around what the CLI or manifest format (Cargo.toml) should look like. We also have a number of large features ‘sort of planned’ for the near-ish future (e.g., templates, custom profiles, build system integration). These might subsume many smaller features in a more orthogonal, minimal manner.

The Cargo team is going to start planning out and prioritising these features over the next couple of months with the goal of having a realistic roadmap for 2019, and an idea of what the CLI and manifest format should look like going forward.

Until that work is done (i.e., until the end of the year), Cargo will have a soft feature freeze: the default response for any PR adding surface area to the CLI or manifest format will be ‘no’. If the work is particularly urgent, such PRs can be nominated for discussion at the Cargo meeting and might be approved. We still very much want to land bug fixes, performance improvements, and new features that do not add surface area; development is still very active (and if you’d like to contribute please ping the Cargo team on Discord or GitHub).


Rustup hasn’t seen a lot of change recently. This is mostly a good thing! It has a well-rounded set of features, and there is nothing that urgently needs fixing or improving (which is not to say it is perfect, of course). The focus for Rustup right now is maintaining stability while dealing with changes such as an increasing number of tools and platforms.

The long-term plan for Rustup is that the common functionality will be moved into Cargo, with Rustup dealing with more specialist workflows. To reflect that plan, ownership of Rustup is moving to the Cargo team.

We would love to have more contributors involved with Rustup (especially if you’re interested in becoming a maintainer of the project). However, review bandwidth for Rustup is very limited. If you would like to work on a feature or major bug fix, please check with the Cargo team before starting to work on PRs to ensure there is someone who can review in a timely manner, and that the benefit/risk ratio is appropriate. In general, only small bug fix PRs will be accepted unless there has been some prior arrangement for review, etc.

Like the Cargo feature freeze, this is intended to be a temporary phase while we deal with the edition, 2019 planning, etc. Rustup and Cargo are key parts of the ecosystem and we don’t want to rush feature work without proper planning and high-level design.


Does limiting “surface area growth” preclude cargo subsuming the duties of xargo?


Probably since I can’t imagine that happening without adding sub-commands or new arguments. However, I don’t think we have any plans for that to happen in the next few months in any case.