-
Notifications
You must be signed in to change notification settings - Fork 38
Description
Original implementation is here: #2281
Context
Displaying base versions in our labels was intended to do the following:
- Help people to understand what version of the product the current docs are about, even if the documented feature was introduced in a prior version
- Clarify our
stacklabel, making it clear that it's referring to our versioned elastic stack, as opposed to its unversioned serverless counterpart.
The problem
We got feedback that always displaying the base version is giving people signals around availability and compatibility that are unintended.
For example, a feature might be introduced in an 8.x version of the stack, but we fall back to the base version to help people to understand that the documentation is referring to the feature as it exists in 9.0+, and the user might need to view our old docs to understand how it worked in previous versions. However, this sends a signal that the feature was introduced in 9.0.
We also have a new use case, where functionality exists in an unversioned product (Elastic Cloud), but offers services to versioned products, such as ECE, ECK, and self-managed deployments. In this case:
- The compatibility is driven by the stack version
- The feature is only available to users on certain deployments
- The functionality is versionless because it's part of Elastic Cloud
This combination of factors makes "base version" signals very noisy and confusing.
The proposal
Do not automatically display base versions in our badges