Factors that reduce compatibility risk include:
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.
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.
Anyone who wants to implement a feature in V8 must contact firstname.lastname@example.org with an “intent to implement” email. Then follow these steps:
At this stage, the feature becomes available in V8 under the
--es-staging flag. The criteria for moving a feature to that stage are:
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 following technical criteria must be met for shipping:
Before landing the CL that enables the flag by default, an “intent to ship” email is sent to to email@example.com and firstname.lastname@example.org. For V8/JS features, this email is just an FYI to blink-dev; it doesn’t need sign-off from Blink API owners.