This table describes the requirements for a feature to be labeled as Alpha, Beta, or Stable. You can find a checklist rendition of this information at Feature Lifecycle Checklist.
| Development (pre-alpha) | Alpha | Beta | Stable | |
| Purpose | Active development of a feature, not for use by end users directly. | 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. Targetted at all users. | Dependable, production hardened |
| Stability | Unknown | 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 | Unknown | Using the feature may have obvious security vulnerabilities. Discovered vulnerabilities will not necessarily be communicated broadly. | Any discovered security vulnerabilities will be publically disclosed and patched. | Any discovered security vulnerabilities will be publically disclosed and patched. |
| Performance | Unknown | 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 | None | No guarantees on backward compatibility. The feature may be dropped 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 | Varies | 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 | Dev features are hidden in auto-generated reference docs. | 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 | None | The schema and semantics of a feature may change in a later software release, without any provision for preserving configuration objects in an existing istio installation API versions can increment faster than the monthly release cadence and the developer need not maintain multiple versions Developers should still 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 | None | 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 | None | 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 | Don't | 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 |