Skip to content

Adds table to dynamic tag logic explanation #1749

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 15 additions & 9 deletions docs/contribute/_snippets/tag-processing.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,17 +2,23 @@

Specifically for versioned products, badges will display differently when the `applies_to` key specifies a product version that has not been released to our customers yet.

* `Planned` (if the lifecycle is preview, beta, or ga)

Example: {applies_to}`stack: ga 99.99`
* `Deprecation planned` (if the lifecycle is deprecated)

Example: {applies_to}`stack: deprecated 99.99`
* `Removal planned` (if the lifecycle is removed)
The following table shows how badges for versioned products are displayed based on the release status for each lifecycle value. Hover over the example badges for the tooltip text.

Example: {applies_to}`stack: removed 99.99`
| Lifecycle | Release status | Badge text |
|-------------|----------------|-----------------------------------------------------------------------------------|
| preview | prerelease | {applies_to}`stack: preview 99.99` |
| | post-release | `<KEY> PREVIEW <VERSION>` <br><br> example: {applies_to}`stack: preview 9.1` |
| beta | prerelease | {applies_to}`stack: beta 99.99` |
| | post-release | `<KEY> BETA <VERSION>` <br><br> example: {applies_to}`stack: beta 9.1` |
| ga | prerelease | {applies_to}`stack: ga 99.99` |
| | post-release | `<KEY> <VERSION>` <br><br> example: {applies_to}`stack: ga 9.1` |
| deprecated | prerelease | {applies_to}`stack: deprecated 99.99` |
| | post-release | `<KEY> DEPRECATED <VERSION>` <br><br> example: {applies_to}`stack: deprecated 9.1`|
| removed | prerelease | {applies_to}`stack: removed 99.99` |
| | post-release | `<KEY> REMOVED <VERSION>` <br><br> example: {applies_to}`stack: removed 9.1` |
Comment on lines +7 to +18
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all examples (right?) because we're showing just one product/deployment method per lifecycle/release status. Can we simplify and just say they are examples in the header for the column and remove the code-formatted text showing the rough format?

Suggested change
| Lifecycle | Release status | Badge text |
|-------------|----------------|-----------------------------------------------------------------------------------|
| preview | prerelease | {applies_to}`stack: preview 99.99` |
| | post-release | `<KEY> PREVIEW <VERSION>` <br><br> example: {applies_to}`stack: preview 9.1` |
| beta | prerelease | {applies_to}`stack: beta 99.99` |
| | post-release | `<KEY> BETA <VERSION>` <br><br> example: {applies_to}`stack: beta 9.1` |
| ga | prerelease | {applies_to}`stack: ga 99.99` |
| | post-release | `<KEY> <VERSION>` <br><br> example: {applies_to}`stack: ga 9.1` |
| deprecated | prerelease | {applies_to}`stack: deprecated 99.99` |
| | post-release | `<KEY> DEPRECATED <VERSION>` <br><br> example: {applies_to}`stack: deprecated 9.1`|
| removed | prerelease | {applies_to}`stack: removed 99.99` |
| | post-release | `<KEY> REMOVED <VERSION>` <br><br> example: {applies_to}`stack: removed 9.1` |
| Lifecycle | Release status | Badge text examples |
|-------------|----------------|---------------------------------------|
| preview | prerelease | {applies_to}`stack: preview 99.99` |
| | post-release | {applies_to}`stack: preview 9.1` |
| beta | prerelease | {applies_to}`stack: beta 99.99` |
| | post-release | {applies_to}`stack: beta 9.1` |
| ga | prerelease | {applies_to}`stack: ga 99.99` |
| | post-release | {applies_to}`stack: ga 9.1` |
| deprecated | prerelease | {applies_to}`stack: deprecated 99.99` |
| | post-release | {applies_to}`stack: deprecated 9.1` |
| removed | prerelease | {applies_to}`stack: removed 99.99` |
| | post-release | {applies_to}`stack: removed 9.1` |


This is computed at build time (there is a docs build every 30 minutes). The documentation team tracks and maintains released versions for these products centrally in [`versions.yml`](https://github.com/elastic/docs-builder/blob/main/config/versions.yml).

This is computed at build time (there is a docs build every 30 minutes). The documentation team tracks and maintains released versions for these products centrally in [`versions.yml`](https://github.com/elastic/docs-builder/blob/main/config/versions.yml).
When multiple lifecycle statuses and versions are specified in the sources, several badges are shown.

:::{note}
Expand Down
Loading