Skip to content

Conversation

cotti
Copy link
Contributor

@cotti cotti commented Sep 10, 2025

Handles #1637

This PR performs a few refactorings into how we deal with product, versioning and legacy URL mapping definitions.

Configuration

  • Substitutions have been added for products to access their labels.
  • Initialization for products.yml and legacy-url-mappings.yml occurs during early service bootstrapping.

Products Listing

  • We now have a products.yml file to gather essential product metadata. Currently, we have a friendly label for each, and reference the versioning system adopted by the project in question.

Versioning

  • Updated to leverage the connection between Product/Version/LegacyURL.

Legacy Url Mapping

  • legacy-url-mappings.yml has been reviewed to include a reference to a product. Most entries have a direct correlation. For a few cases, a best-match approach was taken.

Docs

  • Docs-builder's documentation was updated to reflect these changes.

Copy link
Contributor

@theletterf theletterf left a comment

Choose a reason for hiding this comment

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

@elastic/docs-engineering I think this PR would also solve #1497

What happens with existing product subs define in docset.yml files, by the way? Should we prefer products.yml driven substitutions from now on?

Copy link
Member

@Mpdreamz Mpdreamz left a comment

Choose a reason for hiding this comment

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

A few small nits and q's.

Would be good to include more tests on resolving product names and their attached versioning schemes.

Co-authored-by: Fabrizio Ferri-Benedetti <fabri.ferribenedetti@elastic.co>
Fabrizio with the save.

Co-authored-by: Fabrizio Ferri-Benedetti <fabri.ferribenedetti@elastic.co>
@reakaleek
Copy link
Member

Smoke tests are failing. We should run a full assembler build to validate.

@shainaraskas
Copy link
Contributor

What happens with existing product subs define in docset.yml files, by the way? Should we prefer products.yml driven substitutions from now on?

I share this confusion - can we maybe reference these in docset.yml so we can keep using the same variables?

Copy link
Contributor

@shainaraskas shainaraskas left a comment

Choose a reason for hiding this comment

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

threw some comments on where I could. I suggested a couple of terminology fixes and version # fixes

I'd like to better understand how this actually impacts the functionality of the dropdown - maybe a quick demo could be helpful, or even just explaining using an image of the dropdown what info is populated from where. want to understand what is actually changing with the experience based on these changes

display: 'Elasticsearch Curator'
versioning: 'curator'
ecs:
display: 'Elastic Common Schema (ECS)'
Copy link
Contributor

Choose a reason for hiding this comment

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

do we want brackets on these? @colleenmcginnis

Copy link
Contributor

Choose a reason for hiding this comment

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

It depends on how this value is being used. Recently @KOTungseth requested that we use Elastic Common Schema (ECS) as the page title (elastic/docs-content#2212).

product: elastic-agent
legacy_versions: *stack
en/ingest-overview/:
product: elasticsearch
Copy link
Contributor

Choose a reason for hiding this comment

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

not elasticsearch

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've changed these to elastic-stack for now. Which entry would be more suitable?

product: elasticsearch
legacy_versions: []
en/ingest/:
product: elasticsearch
Copy link
Contributor

Choose a reason for hiding this comment

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

not elasticsearch

product: cloud-serverless
legacy_versions: []
en/starting-with-the-elasticsearch-platform-and-its-solutions/:
product: elasticsearch
Copy link
Contributor

Choose a reason for hiding this comment

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

not elasticsearch

@cotti
Copy link
Contributor Author

cotti commented Sep 16, 2025

threw some comments on where I could. I suggested a couple of terminology fixes and version # fixes

I'd like to better understand how this actually impacts the functionality of the dropdown - maybe a quick demo could be helpful, or even just explaining using an image of the dropdown what info is populated from where. want to understand what is actually changing with the experience based on these changes

For now, the current behavior of the dropdown is maintained - we just have more information wired in to perform further adjustments later on. Usage is the same.

Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
Copy link
Contributor

@shainaraskas shainaraskas left a comment

Choose a reason for hiding this comment

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

this looks good for the products I have knowledge of now (without being able to see how the elements are integrated in practice)

flagged one thing from the dev docs area for search ui versioning

would suggest that someone from the other docs teams (ingest and dev particularly) do a pass at this for product names and versions

legacy_versions: []
en/search-ui/:
product: search-ui
legacy_versions: ['1.24.1', '1.24.0']
Copy link
Contributor

Choose a reason for hiding this comment

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

I think these docs were versionless so there would be no legacy versions. current version is for 1.24+

Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
legacy_versions: [ '0.x' ]
en/apm/agent/dotnet/:
product: apm-agent-dotnet
legacy_versions: [ '1.33.0' ]
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think there should be any legacy versions for APM .NET agent.

Suggested change
legacy_versions: [ '1.33.0' ]
legacy_versions: []

Copy link
Contributor

Choose a reason for hiding this comment

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

It's not clear if legacy_versions should include the latest version or not.

For example, when I build the docs locally using this branch, on the APM Go agent pages, I only see 0.5 in the version dropdown, but I would expect to see 1.x and 0.5.

Screenshot 2025-09-18 at 6 00 47 PM

Similarly, for Stack-versioned pages, I'm seeing the 8.x list start with 8.18 instead of 8.19.

Screenshot 2025-09-18 at 6 08 38 PM

After I get clarity, I'll need to request more updates on the ingest-related items in this file.

Comment on lines +8 to +10
apm-agent-android:
display: 'APM Agent for Android'
versioning: 'apm_agent_android'
Copy link
Contributor

Choose a reason for hiding this comment

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

@theletterf should we remove this in favor of edot-android?

Copy link
Contributor

@theletterf theletterf Sep 19, 2025

Choose a reason for hiding this comment

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

I don't know. It's the same in versions.yml. All new documents use edot_, but the old ones don't. I don't know if keeping this here is required for some backward compatible mechanism. Is it, @cotti?

Otherwise, I would just keep edot_android and edot_ios.

Comment on lines +17 to +19
apm-agent-ios:
display: 'APM Agent for iOS'
versioning: 'apm_agent_ios'
Copy link
Contributor

Choose a reason for hiding this comment

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

@theletterf should we remove this in favor of edot-ios?

Copy link
Contributor

Choose a reason for hiding this comment

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

Comment on lines +110 to +112
edot-sdk:
display: 'Elastic Distribution of OpenTelemetry SDK'
versioning: 'stack'
Copy link
Contributor

Choose a reason for hiding this comment

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

@theletterf does this make sense as a product? It wouldn't have a single versioning system (stack). 🤔

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, nope, it doesn't. Would this be the required edit?

Suggested change
edot-sdk:
display: 'Elastic Distribution of OpenTelemetry SDK'
versioning: 'stack'
edot-sdk:
display: 'Elastic Distribution of OpenTelemetry SDK'
versioning: 'all'

versioning: 'stack'
ess:
display: 'Elastic Cloud Hosted'
versioning: 'all'
Copy link
Contributor

Choose a reason for hiding this comment

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

Is all the same as unversioned?

Copy link
Contributor

Choose a reason for hiding this comment

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

Same question.

Comment on lines +5 to +7
apm-agent:
display: 'APM Agent'
versioning: 'stack'
Copy link
Contributor

Choose a reason for hiding this comment

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

If we keep this and versioning: 'all' means unversioned, I wonder if we should use that since no APM Agent is Stack versioned. 🤔 cc @theletterf

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed — if adding all is indeed the right option to get a versionless product listed.

Suggested change
apm-agent:
display: 'APM Agent'
versioning: 'stack'
apm-agent:
display: 'APM Agent'
versioning: 'all'

theletterf and others added 3 commits September 19, 2025 09:44
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
base: 0.1
current: 0.2.0

# Logging
Copy link
Contributor

Choose a reason for hiding this comment

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

@shainaraskas @colleenmcginnis We can add UpdateCLI automated version bumps for these, too, in a follow-up PR.

theletterf and others added 2 commits September 19, 2025 09:47
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants