Skip to content

Add feature staging guidelines #1881

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add feature staging guidelines #1881

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 17 additions & 2 deletions content/kubermatic/main/architecture/feature-stages/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,10 @@ weight = 4

+++

## Introduction

Feature stages in Kubermatic Kubernetes Platform (KKP) help users understand the maturity and stability of features. This classification system ensures that users can make informed decisions about which features to use in their environments based on their specific needs and risk tolerance.

## Alpha

- Targeted users: internal, or specific customer
Expand All @@ -15,7 +19,6 @@ weight = 4
- The whole feature can be revoked immediately and without notice
- Recommended only for testing and providing feedback


## Beta / Technical Preview

- Targeted users: experienced KKP administrators
Expand All @@ -27,7 +30,6 @@ weight = 4
- The whole feature can still be revoked, but with prior notice and respecting a deprecation cycle
- Recommended for only non-business-critical uses, testing usability, performance, and compatibility in real-world environments


## General Availability (GA)

- Users: All users
Expand All @@ -38,3 +40,16 @@ weight = 4
- All changes to the feature are backwards compatible with an automated migration path implemented where needed
- Removing the feature requires a strict deprecation cycle and replacement or migration path when possible
- Recommended for production use

### Feature Stage Guidelines

- The following components should explicitly be marked as alpha/beta:
- APIs/CRDs: Dedicated CRDs including fields in API and CRD that are introduced for this feature.
- UI: All the views/fields that are used to interact with the feature.
- Example: Add "(Alpha)" or "(Beta)" suffix to feature names in the UI
- Documentation: All the documentation related to the feature.
- Example: Add "This feature is in alpha/beta stage" warning at the top of relevant docs
- Helm chart/Application: All the helm charts and Applications related to the feature.
- Example: Add "This feature is in alpha/beta stage" notice in README.md

**NOTE: For General Availability (GA) features, the above feature stage guidelines are not applicable as the feature is considered production-ready. There is no need to explicitly mark the feature as GA.**
19 changes: 17 additions & 2 deletions content/kubermatic/v2.25/architecture/feature-stages/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,10 @@ weight = 4

+++

## Introduction

Feature stages in Kubermatic Kubernetes Platform (KKP) help users understand the maturity and stability of features. This classification system ensures that users can make informed decisions about which features to use in their environments based on their specific needs and risk tolerance.

## Alpha

- Targeted users: internal, or specific customer
Expand All @@ -15,7 +19,6 @@ weight = 4
- The whole feature can be revoked immediately and without notice
- Recommended only for testing and providing feedback


## Beta / Technical Preview

- Targeted users: experienced KKP administrators
Expand All @@ -27,7 +30,6 @@ weight = 4
- The whole feature can still be revoked, but with prior notice and respecting a deprecation cycle
- Recommended for only non-business-critical uses, testing usability, performance, and compatibility in real-world environments


## General Availability (GA)

- Users: All users
Expand All @@ -38,3 +40,16 @@ weight = 4
- All changes to the feature are backwards compatible with an automated migration path implemented where needed
- Removing the feature requires a strict deprecation cycle and replacement or migration path when possible
- Recommended for production use

### Feature Stage Guidelines

- The following components should explicitly be marked as alpha/beta:
- APIs/CRDs: Dedicated CRDs including fields in API and CRD that are introduced for this feature.
- UI: All the views/fields that are used to interact with the feature.
- Example: Add "(Alpha)" or "(Beta)" suffix to feature names in the UI
- Documentation: All the documentation related to the feature.
- Example: Add "This feature is in alpha/beta stage" warning at the top of relevant docs
- Helm chart/Application: All the helm charts and Applications related to the feature.
- Example: Add "This feature is in alpha/beta stage" notice in README.md

**NOTE: For General Availability (GA) features, the above feature stage guidelines are not applicable as the feature is considered production-ready. There is no need to explicitly mark the feature as GA.**
19 changes: 17 additions & 2 deletions content/kubermatic/v2.26/architecture/feature-stages/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,10 @@ weight = 4

+++

## Introduction

Feature stages in Kubermatic Kubernetes Platform (KKP) help users understand the maturity and stability of features. This classification system ensures that users can make informed decisions about which features to use in their environments based on their specific needs and risk tolerance.

## Alpha

- Targeted users: internal, or specific customer
Expand All @@ -15,7 +19,6 @@ weight = 4
- The whole feature can be revoked immediately and without notice
- Recommended only for testing and providing feedback


## Beta / Technical Preview

- Targeted users: experienced KKP administrators
Expand All @@ -27,7 +30,6 @@ weight = 4
- The whole feature can still be revoked, but with prior notice and respecting a deprecation cycle
- Recommended for only non-business-critical uses, testing usability, performance, and compatibility in real-world environments


## General Availability (GA)

- Users: All users
Expand All @@ -38,3 +40,16 @@ weight = 4
- All changes to the feature are backwards compatible with an automated migration path implemented where needed
- Removing the feature requires a strict deprecation cycle and replacement or migration path when possible
- Recommended for production use

### Feature Stage Guidelines

- The following components should explicitly be marked as alpha/beta:
- APIs/CRDs: Dedicated CRDs including fields in API and CRD that are introduced for this feature.
- UI: All the views/fields that are used to interact with the feature.
- Example: Add "(Alpha)" or "(Beta)" suffix to feature names in the UI
- Documentation: All the documentation related to the feature.
- Example: Add "This feature is in alpha/beta stage" warning at the top of relevant docs
- Helm chart/Application: All the helm charts and Applications related to the feature.
- Example: Add "This feature is in alpha/beta stage" notice in README.md

**NOTE: For General Availability (GA) features, the above feature stage guidelines are not applicable as the feature is considered production-ready. There is no need to explicitly mark the feature as GA.**
19 changes: 17 additions & 2 deletions content/kubermatic/v2.27/architecture/feature-stages/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,10 @@ weight = 4

+++

## Introduction

Feature stages in Kubermatic Kubernetes Platform (KKP) help users understand the maturity and stability of features. This classification system ensures that users can make informed decisions about which features to use in their environments based on their specific needs and risk tolerance.

## Alpha

- Targeted users: internal, or specific customer
Expand All @@ -15,7 +19,6 @@ weight = 4
- The whole feature can be revoked immediately and without notice
- Recommended only for testing and providing feedback


## Beta / Technical Preview

- Targeted users: experienced KKP administrators
Expand All @@ -27,7 +30,6 @@ weight = 4
- The whole feature can still be revoked, but with prior notice and respecting a deprecation cycle
- Recommended for only non-business-critical uses, testing usability, performance, and compatibility in real-world environments


## General Availability (GA)

- Users: All users
Expand All @@ -38,3 +40,16 @@ weight = 4
- All changes to the feature are backwards compatible with an automated migration path implemented where needed
- Removing the feature requires a strict deprecation cycle and replacement or migration path when possible
- Recommended for production use

### Feature Stage Guidelines

- The following components should explicitly be marked as alpha/beta:
- APIs/CRDs: Dedicated CRDs including fields in API and CRD that are introduced for this feature.
- UI: All the views/fields that are used to interact with the feature.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newly introduced features in general should rather always have a switch in the admin panel which turns them fully off and on (besides the feature gate).

Therefore, if the platform admin decides to turn a feature on, it's enough to have these marks for the platform admin, as from that point, it's their responsibility to let their custumers / users use these features. Marking features throughout all the user personas of KKP could be confusing to the end users in several cases.

The possibility to turn a feature on and off by the Platform Admin of KKP should solve this issue, and the Platform Admin should always be 100% aware if a feature is in Beta.

- Example: Add "(Alpha)" or "(Beta)" suffix to feature names in the UI
- Documentation: All the documentation related to the feature.
- Example: Add "This feature is in alpha/beta stage" warning at the top of relevant docs
- Helm chart/Application: All the helm charts and Applications related to the feature.
- Example: Add "This feature is in alpha/beta stage" notice in README.md

**NOTE: For General Availability (GA) features, the above feature stage guidelines are not applicable as the feature is considered production-ready. There is no need to explicitly mark the feature as GA.**