Date-based versioning

[florent-leborgne]

We currently support (or are going to support) Major.Minor.Patch-based versioning.

This discussion is meant to consider use cases where we might need more than that for certain use cases, especially for typically unversioned products like Serverless or Cloud.

One potential need is date-base versioning. For example:

• "if breaking changes are introduced and users need to specify the Elastic-APi-Version in API calls in serverless. At that point we'll need some way to qualify that the content in a particular section (especially if it's full of API examples) is specific to that Serverless date, for example. Hopefully it'll be feasible with an applies_to like "serverless ga YYYY-MM-DD", where YYYY-MM-DD is the Elastic-Api-version from the API header." (quoting @lcawl)

• Another case for this is that with the current system, we cannot merge any serverless or cloud-related change before the change is live in production on the product side, which can be blocking in terms of authoring workflow. Right now, this is not an issue as we tend to document these products very late in the process (often when the feature is already released in the corresponding product...), but as our processes get better and our product release cycles get more organized and predictable, this could become a bigger issue in the future, that we'll need to resolve.

Thoughts?

[lcawl]

I've mentioned this discussion in elastic/kibana#221056 since whatever we do in the narrative docs we'll ideally want to do in the API docs as well.