Release Phases

Ensuring the stability and reliability of our components is essential for building trust and delivering a consistent user experience. To achieve this, we follow a structured release process that guides each component through three distinct phases: Alpha, Beta, and Stable.

This phased approach allows us to:

• Gather meaningful feedback from users and stakeholders
• Validate new features and designs in real-world scenarios
• Communicate the current stability and expected changes for each component
• Minimize unexpected breaking changes and rework after release

By clearly defining what each phase means, we help teams understand when and how to use components, and what to expect in terms of support, documentation, and future changes.

Phase Definitions

Alpha

alpha

What it is: An early, experimental version of a component that is still under active development. Alpha components are intended for internal validation and rapid prototyping, not for production use.

Key characteristics:

• Work in progress — breaking changes are likely and expected
• Not production-ready: code may lack error handling, tests, or polish
• Minimal documentation, usually limited to internal notes
• Feedback is primarily gathered from internal teams and select partners

When to use alpha: Use alpha components for prototypes, design validation, and technical feasibility spikes. They are ideal for exploring new ideas and gathering early feedback before investing in full development.

Beta

beta

What it is: A component that is feature-complete and suitable for production use, but still evolving based on user feedback. Beta components are publicly documented and available for broader testing and validation.

Key characteristics:

• Publicly documented, including usage guidance, limitations, and warnings
• APIs and designs are mostly stable, but may change in response to feedback
• Suitable for pilot projects and limited production use
• Actively seeking feedback from a wider audience to refine and improve the component

When to use beta: Use beta components when the feature is mature enough for real-world use, but still needs broader validation and feedback before being declared stable. Beta is the ideal phase for pilot projects and early adopters.

Stable

new

What it is: A mature component that is production-ready, fully supported, and considered final. Stable components are recommended for all users and projects.

Key characteristics:

• APIs and designs are considered final — breaking changes are rare and only occur with proper deprecation policies
• Fully documented, with comprehensive usage examples and guidance
• Validated in production environments and covered by standard support and maintenance policies

When to use stable: Declare a component stable after successful beta adoption, when feedback has been addressed and there is confidence in its reliability and long-term support.

Why do we use this process?

By following this phased release process, we:

• Reduce unexpected breaking changes and minimize rework after release
• Set clear expectations for stability and support at every stage
• Encourage meaningful feedback and collaboration with users
• Increase trust and adoption of our design system

Ultimately, this approach ensures that every component is robust, well-documented, and ready for production use when marked as stable. It helps teams make informed decisions and build reliable products with confidence.