Feature launch process
Compatibility risk #
Factors that reduce compatibility risk include:
- Interest from other browser vendors. Implementations in other browsers are a clear signal of feature usefulness. In order of strength, this includes:
- compatible implementation in more than one engine
- compatible implementation in one engine
- implementation in one or more engines under an experimental flag
- other vendors expressed interest in the feature
Impact on Web Platform #
In prioritizing the work of implementing new features, we will prefer those which unblock significant new capability, performance or expressiveness.
For every change we implement we want to validate our design and implementation every step of the way. As such, we aim to have a robust set of use cases for new features we implement; ideally, we want to be involved with the community, identifying groups of developers ready and willing to provide feedback for our implementations.
Technical considerations #
- Assessment of the impact on the codebase. V8 is a highly complex and tightly knit codebase with many interdependencies; support cost for particularly pervasive features might be substantial.
- Conformance tests, ideally suitable for future inclusion in ECMA-262 test suite.
- Performance tests.
As the implementation of a particular feature progresses, we expect both conformance and performance test suites to progress in parallel.
Language features implemented in V8 go over three stages: experimental implementation, staging, and shipping without a flag.
Experimental implementation #
Anyone who wants to implement a feature in V8 must contact email@example.com with an “intent to implement” email. Then follow these steps:
- Clarify the feature status with regard to the criteria in the guidelines on this page (TC39 or WebAssembly Community Group acceptance, interest from browser vendors, testing plans) in an “intent to implement” email.
- Provide a design doc to clarify V8 code base impact.
- The implementation should also consider DevTools support. Refer to the debugger support checklist for new language features for more details.
- Implement the feature under a
--experimental-wasm-Xflag for WebAssembly.
- Develop conformance and performance tests in parallel.
At this stage, the feature becomes available in V8 under the
--es-staging flag. The criteria for moving a feature to that stage are:
- The specification of the feature is stable
- One example of feature stability indicator is it being advanced to stage 3 of the TC39 process
- Implementation is mostly complete; remaining issues are identified and documented
- Conformance tests are in place
- Performance regression tests are in place
Turning the flag on — shipping the feature to the open Web #
As the implementation of a feature progresses, we evaluate community feedback on feature design and implementation. The V8 team makes a decision to turn the feature on by default based on the community opinion of the feature and the technical maturity of the implementation.
Some community signals we consider before shipping:
- The feature is on the clear track to standardization at TC39. For example, a feature spec is available and has been through several rounds of reviews, or a feature is at Stage 3+ of the TC39 process.
- There is a clear interest in the feature from other browser vendors. For example, another engine is shipping a compatible implementation in an experimental or stable channel.
The following technical criteria must be met for shipping:
- The implementation is complete; any feedback received from the staged implementation is addressed.
- No technical debt: the V8 team is satisfied with the feature’s implementation quality (including basic DevTools support).
- Performance is consistent with our high-performance goals.
Before landing the CL that enables the flag by default, an “intent to ship” email is sent to to firstname.lastname@example.org and email@example.com. For V8/JS features, this email is just an FYI to blink-dev; it doesn’t need sign-off from Blink API owners.