From c52be1a5b2bd0ee9cd185935214ab88805a12645 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Tue, 6 Feb 2018 01:11:51 +0100 Subject: [PATCH] rfc, roadmap-2018: boost focus on testing --- text/0000-roadmap-2018.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/text/0000-roadmap-2018.md b/text/0000-roadmap-2018.md index b51c53907fa..af1a6c6b358 100644 --- a/text/0000-roadmap-2018.md +++ b/text/0000-roadmap-2018.md @@ -57,6 +57,8 @@ To make our product successful, we should build and market it with an eye toward - **CLI apps**. A place where Rust’s portability, reliability, and ergonomics come together to great effect. - **Embedded** **devices**. A domain with a great deal of potential that is not yet first-class. +To gain confidence in ecosystem quality and reliability, we will also focus on providing great **testing libraries** with which crates in these four domains can be tested. + Looking at the year as a whole, with our second marketing release of Rust, @nrc perhaps put it best: @@ -147,12 +149,13 @@ Compiler work will center on: > [The core team should participate in prioritizing and implementing quality crates for productivity needs.](https://medium.com/@nimtiazm/rust-and-crate-of-wishes-for-2018-1258f6977d42) (@nimtiazm) -In preparation for the epoch release, we will continue to invest in Rust’s library ecosystem in three ways: +In preparation for the epoch release, we will continue to invest in Rust’s library ecosystem in four ways: - **Quality**. Building on our 2017 work, we will bring the API Guidelines to a 1.0 status and build out additional resources to aid library authors. - **Discoverability**. We will continue to work with the crates.io team on discoverability improvements, as well as push the Cookbook (or something like it) to 1.0 status as a means of discovering libraries. - **Domain-specific content**. We will work with library authors in the four domains of focus this year to sharpen our offerings in each domain (elaborated more below). +- **Testing**. To ensure the quality of these offerings, we will also work with authors of testing libraries to make testing easy and more widely used. A working group for testing, reporting to the core team, will be formed to consolidate efforts and strive for better integration. #### Documentation @@ -185,7 +188,7 @@ Beyond these clear-cut items, there are a number of ongoing efforts, some of whi And a couple of goals that are probably a stretch for 2018 at all, let alone for the epoch release: -- **Custom test frameworks**. There’s been [a lot of interest in this area](https://internals.rust-lang.org/t/past-present-and-future-for-rust-testing/6354/1), and it may be possible that with a dedicated working group we can implement and stabilize test frameworks in 2018. +- **Custom test frameworks**. There’s been [a lot of interest in this area](https://internals.rust-lang.org/t/past-present-and-future-for-rust-testing/6354/1), and it may be possible that with a dedicated working group we can implement and stabilize test frameworks in 2018. If not, custom test frameworks should at least be available as an unstable feature and a merged eRFC, such as [RFC 2318](https://github.com/rust-lang/rfcs/pull/2318), with which we may gain confidence. - **Compiler-driven code completion for the RLS**. Today the RLS still uses a purely heuristic approach for auto-completion. If the compiler’s new “query-based” architecture can be pushed far enough during the year, it maybe become feasible to start using it to deliver precise auto-complete information. #### Web site