Problem
In the {settings} directive, when a setting's applies_to.stack only points at versions greater than the current released stack, the inline stack badge correctly renders as Planned, but the Supported on line can still list ECH, Self-managed, etc. as if the setting were available today. This is misleading: ECH, ECE, ECK, and Self-managed all run the Elastic Stack, so a setting that has not shipped in any released stack version cannot actually be used on those surfaces.
Example
The Internationalization settings in Kibana page shows i18n.defaultLocale with:
- inline badge: Stack | Planned
- supported on: ECH, Self-managed
A user tried to set this on ECH and it did not work — the setting is planned for Kibana 9.5.0. Discussion: Slack thread.
Proposed behaviour
Hide the Supported on line for any individual setting whose applies_to.stack is non-null and where every entry has a Version.Min greater than the current stack version. Settings with mixed past + future stack entries (e.g. stack: ga 9.0, deprecated 9.5) are still usable today, so the line stays. Settings with no stack: at all are unaffected.
Known edge case
A setting with stack: ga 9.5 AND serverless: ga would also have its Supported on line hidden, even though it exists on serverless today. Per the Slack thread, the settings corpus is published from Kibana main precisely because serverless usually runs ahead of stack, so this combination is not theoretical. For v1 we hide; if pages surface where this loses useful info we can narrow the rule (e.g. only hide when the would-be Supported-on badges are all deployment-stack-bound: ECH, ECE, ECK, Self-managed).
Related
PR: #3407
Problem
In the
{settings}directive, when a setting'sapplies_to.stackonly points at versions greater than the current released stack, the inline stack badge correctly renders as Planned, but the Supported on line can still listECH,Self-managed, etc. as if the setting were available today. This is misleading: ECH, ECE, ECK, and Self-managed all run the Elastic Stack, so a setting that has not shipped in any released stack version cannot actually be used on those surfaces.Example
The Internationalization settings in Kibana page shows
i18n.defaultLocalewith:A user tried to set this on ECH and it did not work — the setting is planned for Kibana 9.5.0. Discussion: Slack thread.
Proposed behaviour
Hide the Supported on line for any individual setting whose
applies_to.stackis non-null and where every entry has aVersion.Mingreater than the current stack version. Settings with mixed past + future stack entries (e.g.stack: ga 9.0, deprecated 9.5) are still usable today, so the line stays. Settings with nostack:at all are unaffected.Known edge case
A setting with
stack: ga 9.5ANDserverless: gawould also have its Supported on line hidden, even though it exists on serverless today. Per the Slack thread, the settings corpus is published from Kibanamainprecisely because serverless usually runs ahead of stack, so this combination is not theoretical. For v1 we hide; if pages surface where this loses useful info we can narrow the rule (e.g. only hide when the would-be Supported-on badges are all deployment-stack-bound: ECH, ECE, ECK, Self-managed).Related
PR: #3407