Hey folks!
I'm on a bit of a mission to find a way to make it easier to gather stabilization evidence for "high impact" unstable features. By "high impact" here I don't mean "enables lots of cool stuff", but rather "meaningfully improves the quality of life of many developers". What I'm after may be easier to explain by way of a concrete example (feel free to skip it by jumping to the next horizontal line).
I currently maintain the Rust integration for AWS' internal build system. It is used by more or less all Rust projects throughout the organization, and thus any given change to it has an outsized impact, whether positive or negative. In cases where the integration between the internal build system and cargo isn't frictionless, that pain is generally felt by every engineer using Rust, which can add up to a lot of frustration. Recently, I landed a cargo feature, -Zpatch-in-config
, that would address a long-standing pain-point in the Cargo integration. I have tested it myself, and it significantly improves the experience for certain common use-cases. And if it were to be deployed internally, it would solve a bunch of issues internal developers are experiencing.
Unfortunately, since it's an unstable nightly feature, I don't have a good way to test it throughout the organization. Switching to nightly isn't really an option, since at this kind of scale issues introduced to nightly will almost certainly break something, so the broad stability of stable is important. I could use the RUSTC_BOOTSTRAP=1
hack to break Rust's stability guarantees combined with -Zallow-features
, but that just feels icky.
The fact that I don't have a good way to test this feature widely internally in turn means that I can't easily provide good stabilization evidence back upstream. And since this change is only likely to be useful for those integrating Cargo with other build systems at scale, chances are such evidence simply won't be reported. This is bad for the ecosystem. So, I'm trying to come up with a better way to go about this that might be applicable beyond my particular use-case.
This isn't the first time this problem has been pointed out, or solutions proposed. In fact, we've been around this a few times now:
- The case for a new relese channel: testing (2020 take 2)
- Mechanism for beta testing unstable features (2020)
- Getting more testing of unstable features (2017)
- Allow unstable features on beta? (2015)
Rather than try to propose a(nother) solution in this thread, I'd like to first try to solicit other examples of such "high impact" changes, defined roughly as:
- Big fan-out. Enabling the use of this feature in one place (e.g., a single build system or a single crate) would meaningfully and positively impact a large number of developers. "Large" is subjective of course, but I'd say at least 100+ developers.
- Stable implementation. The feature is unlikely to see significant changes before landing, and is either simple enough, or has gone through enough revisions that it'd be meaningful to test it on stable. This is important because if that's not the case, chances are it's best for the feature to be tested on nightly for the time being anyway.
- No cascade. The feature is impactful when enabled only at the "top level", be it at a crate with no dependents or in an external system. This is an important condition, as features that do not meet this requirement very quickly start violating Rust's stability guarantees.
If you can think of a feature that matches those criteria, I'd love to hear about it! That way, I'll be armed with a good list from which to try and craft a mechanism that might enable testing these kinds of features on the beta and stable channels! If you could include
- the name of the feature and whether it is for Rust or Cargo
- a link to the feature's section in the Rust Unstable Book or the Cargo Unstable Features listing
- a brief outline of the feature's (potential) impact
that'd be amazing! I'll go first:
Feature: patch-in-config
(Cargo)
Impact: Would save Rust developers at AWS (there are many of us ) from wiping their build artifacts and lockfiles whenever first-party dependencies change.