Expanding the "applies to" frontmatter

[bmorelli25]

Discussed in #452

^{Originally posted by lcawl February 7, 2025}
I think as we wrestle with "real" content we're discovering a need for more facets in the applies to frontmatter.

In particular, we need:

• A way to separate the product and its version (e.g. Elastic stack v9.0) from the deployment type (e.g. on-prem, serverless, cloud hosted, ECE, ECK, etc). The current usage of "stack" to represent both the Elastic Stack version and the self-managed/on-prem environment is proving to be unclear (since "Elastic Stack" also exists on cloud hosted, ECE, and ECK).
• Per deprecated and removed features #413, we need more nuance around the lifecycle details (i.e. when the behaviour described in the page first became available, whether it's experimental or deprecated, and when it was removed) since the page can span multiple stages of availability. Right now I think it can only display one of those stages per deployment type.

I think we'll also eventually need:

• A way to specify the versions for non-stack-versioning products (for example, this arose when I was looking at the ECS logging content set and might also arise for things like APM agent docs). We might be okay for now but will need to have a way to accommodate those divergent schemes eventually.
• Frontmatter that captures the specific project types within serverless (e.g. we have some features that are rolled out to only a subset of the features at a particular point in time). We can cover this in text for now but might be nice to enable filtering on this in the future.

For example, maybe this means updating like this:

applies to:
  <deployment>: [lifecycle] [version]
  <product>: [lifecycle] [version], [lifecycle] [version], ...

Which would enable us to have scenarios like this:

applies to: 
  stack: beta 9.0, ga 9.1.1, deprecated 9.5, removed 10.0
  ecs: 8.17+
 apm-dotnet: 1.x
 serverless: all
 on-prem: all
 cloud: all

(this is a nonsense combination, just to demonstrate the types of products that currently have different release cadences and schemes).

The tricky part will be communicating things that are availability (or unavailable) at different stages as things get rolled from serverless to on-prem, for example. Maybe the only way to cover that in the metadata is to nest the fields? For example:

applies to: 
 serverless:
    observability: beta 2025-02-02, ga 2025-03-03
    security: beta 2025-0303
 on-prem:
    stack: beta 9.0, ga 9.1.1, deprecated 9.5, removed 10.0
 cloud: all

Note that I don't think we necessarily have to show all this information at the top of the page (maybe some of the historic lifecycle information is not shown or is only shown in a less-obtrusive section at the bottom of the page). Or maybe it's eventually used for a custom filtered view.

[bmorelli25]

Don't forget to also implement #413