This table describes the requirements for a feature to be labeled as Alpha, Beta, or Stable. Once a feature meets the Alpha label criteria, the feature may be included in the feature status page on Istio's Website. You can find a checklist rendition of this information at Feature Lifecycle Checklist.
| Experimental | Alpha | Beta | Stable | |
| Purpose | Feature is under active development and user facing APIs may change. Users should deploy experimental features with extreme caution, preferably in non-production environments as experimental versions may require a migration effort. | Used to get feedback on a design or feature or see how a tentative design performs, etc. Targeted at developers and expert users. | Used to vet a solution in production without committing to it in the long term, to assess its viability, performance, usability, etc. Targeted at all users. | Dependable, production hardened |
| Stability | May be buggy. Using the feature may expose bugs. Not active by default. | May be buggy. Using the feature may expose bugs. Not active by default. | Code is well tested. The feature is safe for production use. | Code is well tested and stable. Safe for widespread deployment in production. |
| Security | Using the feature may have obvious security vulnerabilities. Discovered vulnerabilities may not be communicated broadly. | Using the feature may have obvious security vulnerabilities. Discovered vulnerabilities may not be communicated broadly. | Any discovered security vulnerabilities will be publicly disclosed and patched. | Any discovered security vulnerabilities will be publicly disclosed and patched. |
| Performance | Performance characteristics are unknown. Enabling the experimental feature may adversely affect performance. | Performance requirements are assessed as part of design. | Performance and scalability are characterized, but may have caveats. | Perf (latency/scale) is quantified and documented, with guarantees against regression. |
| Support | No guarantees on backward compatibility. The feature may be removed at any time without notice. | No guarantees on backward compatibility. The feature may be removed at any time without notice. | The overall feature will not be dropped, though details may change. | The feature will appear in released software for many subsequent versions. |
| Deprecation Policy | None, feature can be removed at any time | None, feature can be removed at any time | Weak, feature can be removed with 3 months of advanced notice | Strong, feature can be removed with 1 year of advanced notice, but there will usually be a supported upgrade path to a replacement feature |
| Versioning | The API version name contains dev (e.g. v1dev1) | The API version name contains alpha (e.g. v1alpha1) | The API version name contains beta (e.g. v2beta3) | The API version is vX where X is an integer (e.g. v1) |
| Availability | The feature may or may not be available in the main Istio repo. The feature may or may not appear in an Istio release. If it does appear in an Istio release it will be disabled by default. The feature requires an explicit flag to enable in addition to any configuration required to use the feature, in order to turn on dev features. | The feature is committed to the Istio repo The feature appears in an official Istio release The feature requires explicit user action to use, e.g. a flag flip, use of a config resource, an explicit installation action, or an API being called. When a feature is disabled it must not affect system stability. Note: While Istio is pre-1.0, some alpha features are enabled by default. Post 1.0 alpha features will require explicit action. | In official Istio releases Enabled by default | Same as Beta |
| Audience | Other developers closely collaborating on a feature or proof-of-concept. | The feature is targeted at developers and expert users interested in giving early feedback | Users interested in providing feedback on features | All users |
| Completeness | Feature has limited capabilities. This feature may act as a proof of concept. | Some API operations or CLI commands may not be implemented The feature need not have had an API review (an intensive and targeted review of the API, on top of a normal code review) | All API operations and CLI commands should be implemented End-to-end tests are complete and reliable The API has had a thorough API review and is thought to be complete, though use during beta frequently turns up API issues not thought of during review | Same as Beta |
| Documentation | Experimental features are marked as experimental in auto-generated reference docs or they are not exposed. | Alpha features are marked alpha in auto-generated reference docs. Basic documentation describing what the feature does, how to enable it, the restrictions and caveats, and a pointer to the issue or design doc the feature is based on. | Complete feature documentation published to istio.io In addition to the basic alpha-level documentation, beta documentation includes samples, tutorials, glossary entries, etc. | Same as Beta |
| Upgradeability | The schema and semantics of an experimental feature may change in newer versions without any guarantees of preserving backwards compatibility requiring configuration changes during upgrades. API versions may increment faster than the monthly release cadence and developers are not required to maintain multiple versions for backwards compatibility. Developers are encouraged to increment the API version when schema or semantics change in an incompatible way | The schema and semantics of an alpha feature may change in a later software release, without any provision for preserving configuration objects in an existing istio installation API versions may increment faster than the monthly release cadence and the developer need not maintain multiple versions Developers should increment the API version when schema or semantics change in an incompatible way | The schema and semantics may change in a later software release When this happens, an upgrade path will be documented In some cases, objects will be automatically converted to the new version In other cases, a manual upgrade may be necessary A manual upgrade may require downtime for anything relying on the new feature, and may require manual conversion of objects to the new version When manual conversion is necessary, the project will provide documentation on the process | Only strictly compatible changes are allowed in subsequent software releases |
| Testing | The presence of the feature must not affect any released features. | The feature is covered by unit tests and integration tests where the feature is enabled and the tests are non-flaky. Tests may not cover all corner cases, but the most common cases have been covered. Testing code coverage >= 70%. When the feature is disabled it does not regress performance of the system. | Integration tests cover edge cases as well as common use cases. Integration tests cover all issues reported on the feature. The feature has end-to-end tests covering the samples/tutorials for the feature. Test code coverage is >= 80%. | Superset of Beta, including tests for any issues discovered during Beta. Test code coverage is >= 90%. |
| Reliability | The user should not expect the feature to be reliable may be untested. | Because the feature is relatively new, and may lack complete end-to-end tests, enabling the feature via a flag might expose bugs which destabilize Istio (e.g. a bug in a control loop might rapidly create excessive numbers of objects, exhausting API storage). | Because the feature has e2e tests, enabling the feature should not create new bugs in unrelated features. Because the feature is relatively new, it may have minor bugs. | High. The feature is well tested and stable and reliable for all uses. |
| Support | There is no commitment from the Istio community to improve, maintain or complete the feature and the feature may be dropped entirely in a newer release | There is no commitment from Istio to complete the feature The feature may be dropped entirely in a later software release | Istio commits to complete the feature, in some form, in a subsequent Stable version Typically this will happen within 3 months, but sometimes longer Releases should simultaneously support two consecutive versions (e.g. v1beta1 and v1beta2; or v1beta2 and v1) for at least one supported release cycle (typically 3 months) so that users have enough time to upgrade and migrate resources. | The feature will continue to be present for many subsequent releases. |
| Recommended Use Cases | In short-lived development or testing environments, geared towards soliciting early feedback from users to shape development efforts. | In short-lived development or testing environments, due to complexity of upgradeability and lack of long-term support. | In development or testing environments. In production environments as part of an evaluation of the feature in order to provide feedback. | Any |