1. Experimental
Purpose: Rapid exploration and validation. Features in the Experimental phase are in their earliest stage of development. These features are typically developed in close collaboration with select partners, often with a focus on solving specific, well-defined problems.- Expectations: Frequent and dramatic changes. Features may be reimagined, significantly altered, or even scrapped based on early feedback.
- Audience: A small, curated group of users who agree to participate in shaping the feature.
- Documentation: Minimal to none, as the functionality is highly fluid.
- Goal: Validate the value and approach of the feature while prioritizing speed and flexibility.
2. Beta
Purpose: Refinement for long-term maintainability. Once validated, features enter the Beta phase, where development focuses on stability, scalability, and usability.- Expectations: More stable than Experimental, but still subject to changes based on user feedback.
- Audience: Available to a broader group of customers whose needs align with the feature’s current capabilities.
- Documentation: Features are publicly documented as Beta to enable better adoption and feedback.
- Goal: Gather sufficient feedback to refine the feature for eventual General Availability.
3. Public Preview
Purpose: Broader exposure to gather insights. Public Preview features are nearly complete and unlikely to undergo major changes before their official launch.- Expectations: Stable and close to GA, though not recommended for production use.
- Audience: Open to all users to explore and test the feature.
- Documentation: Fully documented and labeled as Public Preview.
- Goal: Final validation and preparation for General Availability.
4. Limited Availability
Purpose: Controlled rollout for production validation. Features in Limited Availability are available to select customers for production use under controlled conditions.- Expectations: Stable and supported in a limited scope (specific regions or infrastructure).
- Audience: Select customers whose use cases match the feature’s intended purpose.
- Documentation: Fully documented but restricted to qualified users.
- Goal: Validate real-world performance before scaling globally.
5. Generally Available (GA)
Purpose: Official release for production use. GA features are fully integrated into the platform, forming the backbone of the Ebrai ecosystem.- Expectations: Stable, widely available, and actively supported.
- Audience: Available to all users and recommended for production environments.
- Documentation: Fully documented as core platform functionality.
- Goal: Continuous improvement based on user feedback and real-world usage.
6. Deprecated
Purpose: Transition from active development to retirement. Deprecated features remain functional but are no longer actively developed except for critical security fixes.- Expectations: Users are encouraged to migrate to newer alternatives.
- Audience: Existing users of the feature, with notifications and migration guides provided.
- Documentation: Marked as Deprecated in the platform and documentation.
- Goal: Provide a clear pathway for migration to updated solutions.
7. End of Life (EOL)
Purpose: Formal removal of a feature. EOL marks the end of a feature’s lifecycle, where it is no longer available or supported.- Expectations: Features are removed after an announced deprecation period.
- Audience: Notifications provided to affected users well in advance.
- Documentation: Removal is documented, with alternative recommendations provided.
- Goal: Maintain platform efficiency and relevance by retiring obsolete functionality.
Conclusion Ebrai’s development lifecycle reflects our commitment to innovation, collaboration, and reliability. By clearly defining and communicating the maturity of features, we ensure our users can make informed decisions while contributing to the growth and evolution of the platform. For questions or additional details on specific features, please contact our support team or visit the feature documentation in the Success Center.