Product Release Stages
Product release stages describe how we stage, release, and retire product functionality. Product features may not progress through all release stages, and the time in each stage will vary depending on the scope and impact of the feature.
Beta (both public and private) releases give subscribers time to explore new product capabilities while providing feedback prior to a next stage release (can be First Availability or General Availability depending on the feature). Functionality is code-complete and useful in a variety of scenarios but might have changes on its road to a GA release. Beta releases may be restricted to a select number of subscribers (private) or open to all subscribers (public).
When participating in a beta release, you should understand the following:
Functionality is feature complete, but we do not yet support it for production use.
Breaking changes may occur, and we will do our best to communicate them.
Your feedback will help prioritize improvements and fixes in a subsequent release.
Beta releases are subject to our Beta Service Terms.
First Availability releases are expected to be stable and believed to meet quality expectations for a GA release. Minor changes can be expected on its road to GA. The feature is supported and it can be used in production tenants. First Availability releases may be restricted to a select number of subscribers or rolled out to an entire locality (i.e. Tenants hosted in the Japan locality only).
General availability releases are fully functional and available to all subscribers (limited by pricing tier) for production use. If a new release replaces an existing feature, we provide a period of backward compatibility in accordance with our deprecation policy and inform customers so they have time to adopt the new release.
Deprecated features are not supported for use by new subscribers, are not actively being enhanced, and are being only minimally maintained. Tenants using the feature at the time of deprecation will continue to have access.
Deprecation begins when we introduce new behavior that customers would experience as a breaking change without mediation and ends when the old behavior moves into the End of Life product release stage. During Deprecation, customers should engage in a migration to move away from the deprecated feature or behavior. See Migration Process for details.
Although we know that deprecations can be disruptive, they are necessary to allow us to upgrade technology, improve security and quality, and continue to invest in resources that provide the most value for our customers. We are committed to transparency, so we try to proactively notify subscribers when deprecations result in breaking changes or cause altered use of Auth0. Additionally, we try to provide end-of-life notices with accompanying recommendations for migration and replacement capabilities where available.
End of life
Features that reach the end of life stage are removed from the platform. Continued use of these features will likely result in errors.