version docs #451
version docs #451
Conversation
docs/versions-types.md
Outdated
|
|
||
| * **Elasticsearch / Kibana flavor:** The feature base used for basic functionality. Either **Serverless** (sometimes "Elastic Stack Serverless") or **Stack <version>** | ||
|
|
||
| % TODO: Final term for "Stack" |
There was a problem hiding this comment.
Please see discussion here: #452 (comment)
stack now has a defined meaning.
There was a problem hiding this comment.
this comment is meant to reflect ambiguity that the diagram does not address.
docs/versions-types.md
Outdated
|
|
||
| All deployment types other than **Serverless** use the **Stack <version>** flavor of Elasticsearch / Kibana. | ||
|
|
||
| % TODO: Final term for "Self-managed" |
| * There is a single "source of truth" for each feature, which helps us to maintain consistency, accuracy, and maintainability of our documentation over time, and avoids "drift" between multiple similar sets of documentation. | ||
| * Comparing and contrasting differences helps users to understand what is available to them, and improves awareness of the ways certain offerings might improve their experience. | ||
|
|
||
| ::::{note} |
There was a problem hiding this comment.
Who is maintaining this page and do we have a plan to update this content as our approach changes?
There was a problem hiding this comment.
I think it will definitely need to be a living document, especially as the outstanding enhancement requests are resolved and new version releases (9.1) or versioning schemes (e.g. for serverless) need to be considered. I think since this is a public repo and ideally visible to all our internal and external contributors, we should ultimately set a codeowner so that changes are always reviewed by someone from docs. If that's not what you're asking and there's some other place ownership needs to be tracked, lmk!
docs/versions/index.md
Outdated
|
|
||
| | Facet | Description | | ||
| | --- | --- | | ||
| | **Stack flavor** | The Elasticsearch or Kibana feature base used for basic functionality. Either **Serverless** (sometimes "Elastic Cloud Serverless") or **{{stack-short}} <version>** | |
There was a problem hiding this comment.
Using serverless for stack flavor and deployment type is going to get confusing for users.
There was a problem hiding this comment.
This isn't really a Stack flavor. It specifies the Elastic Stack version vs versionless.
| To create a space: | ||
|
|
||
| :::::{tab-set} | ||
| :group: serverless-stack |
There was a problem hiding this comment.
Is our use case to compare Serverless vs Elastic Stack? Or Serverless vs Elastic Stack?
There was a problem hiding this comment.
I think the intention in this particular case is to compare the "Elastic Cloud Serverless" behaviour vs all the other contexts where the relevant Elastic Stack features are supported (e.g. self-managed and all other Cloud contexts). The problem is we still don't have a word for the "everything but serverless" context.
|
|
||
| #### Required permissions | ||
|
|
||
| * **{{serverless-short}}**: `Admin` or equivalent |
There was a problem hiding this comment.
This is unnecessary. This should appear as:
- In serverless, use
Adminor equivalent - In 9.0.0, use
kibana_adminor equivalent
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
|
|
||
| * Each space has its own saved objects. | ||
| * Users can only access the spaces that they have been granted access to. This access is based on user roles, and a given role can have different permissions per space. | ||
| * Each space has its own navigation. **[{{stack}} v9 only]** |
There was a problem hiding this comment.
|
|
||
| | Facet | Description | | ||
| | --- | --- | | ||
| | **Stack flavor** | The Elasticsearch or Kibana feature base used for basic functionality. Either **Serverless** (sometimes "Elastic Cloud Serverless") or **{{stack}} <version>** | |
There was a problem hiding this comment.
|
|
||
| **How many facets do I need to use?** | ||
|
|
||
| The role of these labels is providing a trust signal that the reader is viewing content that’s applicable to them. This means that the relevant labels should appear on all pages. However, we can choose to expose only one versioning facet on pages where only one facet is relevant: |
There was a problem hiding this comment.
|
|
||
| * Depending on what you're documenting, you might need to include information from multiple facets. For example, when relevant features exist at both the stack and the deployment level, both of these groups might be used together (e.g. security, user management, and trust features differ both at the deployment level and at the stack version level). | ||
|
|
||
| * In some sections, such as **Explore and analyze**, features generally only differ by stack flavor. In these cases, you can choose to include only this facet on the page. |
There was a problem hiding this comment.
|
I've created #475, which comments out two sections and makes a few other minor changes to hopefully allow us to move forward with a minimal set of guidelines for now. |
No description provided.