Crossplane logo
Crossplane logo
  • Why Control Planes?
  • Documentation
  • Community
  • Blog
  • Crossplane GitHub
  • Crossplane Slack
Crossplane Documentation - v
Welcome
What's Crossplane?
What's New in v2?
Get Started
Install Crossplane
Get Started With Composition
Get Started With Managed Resources
Get Started With Operations
Composition
Composite Resources
Composite Resource Definitions
Compositions
Composition Revisions
Environment Configs
Managed Resources
Managed Resources
Managed Resource Definitions
Managed Resource Activation Policies
Usages
Operations
Operations
Cron Operations
Watch Operations
Packages
Providers
Functions
Configurations
Image Configs
Guides
Crossplane Pods
Metrics
Function Patch and Transform
Releasing Crossplane Extensions
Write a Composition Function in Go
Write a Composition Function in Python
Disabling Unused Managed Resources
Implementing safe-start in Providers
Troubleshoot Crossplane
Upgrade Crossplane
Upgrade to Crossplane v2
Uninstall Crossplane
CLI Reference
Command Reference
API Reference
Learn More
Release Cycle
Feature Lifecycle
Contributing Guide
Crossplane Roadmap
v2.0
Latest
master v2.0-preview v2.0
Latest
v1.20 v1.19

Feature Lifecycle

On this page
Feature lifecycle
  • Alpha features
  • Beta features
  • GA features
Report a problem
View page source

Feature lifecycle

Crossplane follows a similar feature lifecycle to upstream Kubernetes. Crossplane adds all major new features in alpha. Alpha features graduate to beta, and then to general availability (GA). Features that languish at alpha or beta may be subject to deprecation.

Alpha features

Alpha features are off by default, and you must enable them by a feature flag, for example --enable-composition-revisions. API types for alpha features use a vNalphaN style API version, like v1alpha. Alpha features are subject to removal or breaking changes without notice, and aren’t considered ready for use in production.

Sometimes alpha features require Crossplane to add fields to existing beta or GA

API types. In these cases you must mark fields (for instance in their OpenAPI

schema) as alpha and subject to alpha API constraints (or lack thereof).

All alpha features should have an issue tracking their graduation to beta.

Beta features

Beta features are on by default, but you may disable them by a feature flag. API types for beta features use a vNbetaN style API version, like v1beta1. Crossplane considers beta features to be well tested, and doesn’t removed without Crossplane marking them deprecated for at least two releases.

The schema and/or semantics of objects may change in incompatible ways in a later beta or stable release. When this happens, the team provides instructions for migrating to the next version. This may require deleting, editing, and recreating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.

Sometimes beta features require Crossplane to add fields to existing GA API types. In

these cases you must mark fields (for instance in their OpenAPI schema) as beta

and subject to beta API constraints (or lack thereof).

All beta features should have an issue tracking their graduation to GA.

GA features

GA features are always enabled - you can’t disable them. API types pertaining to GA features use vN style API versions, like v1. GA features are widely used and well tested. They guarantee API stability - Crossplane only allows backward compatible changes.

Crossplane logo
Twitter
Youtube
Podcast
Forum

© Crossplane Authors 2025. Documentation distributed under CC-BY-4.0.

© 2025 The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.

cncfLogo

We are a Cloud Native Computing Foundation incubating project.