⚠ This page is served via a proxy. Original site: https://github.com
This service does not collect credentials or authentication data.
Skip to content

Conversation

@eedugon
Copy link
Contributor

@eedugon eedugon commented Jan 13, 2026

Improvement of the available stack versions on ECH.

Closes #1397

Needs elastic/docs-builder#2454 to be able to render the previous minor version ({{version.stack | M.M-1 | M.M }}). If we don't add that feature we can hardcode the example in the doc, but it would look much better showing always the latest 2 minors that are available, for reference purposes.

Update: to be able to create the preview properly I'm temporary changing the mutation to {{version.stack | M.M+1 | M.M }} for reference purposes.

@eedugon eedugon requested a review from a team as a code owner January 13, 2026 10:41
@eedugon eedugon requested a review from jakommo January 13, 2026 10:42
@github-actions
Copy link
Contributor

github-actions bot commented Jan 13, 2026

Vale Linting Results

Summary: 2 suggestions found

💡 Suggestions (2)
File Line Rule Message
deploy-manage/deploy/elastic-cloud/available-stack-versions.md 36 Elastic.Versions Use 'or earlier' instead of 'or older' when referring to versions.
deploy-manage/deploy/elastic-cloud/available-stack-versions.md 36 Elastic.WordChoice Consider using 'copy' instead of 'clone', unless the term is in the UI.

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 13, 2026

🔍 Preview links for changed docs

Copy link
Contributor

@yetanothertw yetanothertw left a comment

Choose a reason for hiding this comment

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

👍

Copy link
Contributor

@jakommo jakommo left a comment

Choose a reason for hiding this comment

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

Thank you Edu! Left two small comments. But LGTM

* {{version.stack | M.M }} and {{version.stack | M.M+1 | M.M }}
* 8.19

Additional versions can appear in the UI, such as [release candidate builds](#ec-release-builds) or older versions. If a version is listed in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body), it can be deployed.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Additional versions can appear in the UI, such as [release candidate builds](#ec-release-builds) or older versions. If a version is listed in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body), it can be deployed.
Additional versions can appear in the UI, such as [release candidate builds](#ec-release-builds) or older versions that you have a running deployment on. If a version is listed in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body), it can be deployed.

There might be better ways to say thif, but basically if you run a non-EOL version that doesn't match the definition in https://github.com/elastic/docs-content/pull/4607/changes#diff-6f210dc543344c05d32b32b3e89f7efa7fbccb88e4bc6baeabd1394ff341ced2R29-R30 they will also show up as available version to allow spinning up a clone to test upgrades etc.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great point @jakommo , I'll find a way to include your first statement properly, so users understand that they will also have available their "currently used" versions as long as they are supported.

About your second question:

Should we also add a link to https://www.elastic.co/docs/reference/cloud/cloud-hosted/ec-api-deployment-crud#ec_using_the_api_to_create_deployment_with_non_eol_versions and say that any non-EOL version can be deployed via API?

That's your & PM decision I'd say. I don't have any strong opinion. Considering your background and experience in this area, I'd do whatever you suggest, or if you prefer to double check with a PM that's totally ok too.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd say let's add a link to the API instructions. It's already in the public docs and if a user reaches out to support we well them the same, so I see no reason to "hide" this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changes done, I'm requesting a new review from you @jakommo .
I've included the link to the API instructions and also refined a bit the previous sentence.

Let us know your thoughts.
And of course we won't merge this until the formula M-1 is ready, as currently I'm showing an incorrect example :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Issue]: Actually explain which versions will be available in ECH

4 participants