Add version numbers for all settings in the docs

[Swiddis]

Description

While debugging an oncall ticket, having the version number specified for plugins.query.buckets was super useful. I was so inspired I wanted to do it with all the rest of our settings, too.

Related Issues

Minor inconveniences with finding the version in which a config became available.

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

Documentation

• Added comprehensive version metadata annotations to settings documentation, enabling users to easily identify when each configuration option became available.
• Reorganized and standardized version information placement across documentation for improved consistency and discoverability.
• Updated version references to reflect accurate availability information for documented configuration settings.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Walkthrough

Documentation files for settings add version metadata blocks to settings entries across two formats. Version information is introduced as structured subsections or blocks, with one reference value updated from 3.4.0 to 3.4. No functional or behavioral changes to the settings themselves.

Changes

Cohort / File(s)	Summary
Settings Documentation Versioning docs/user/admin/settings.rst, docs/user/ppl/admin/settings.md	Added version metadata blocks to setting entries. In .rst file, version information added preceding descriptions. In .md file, version subsections introduced before description sections. One default value reference updated from 3.4.0 to 3.4. Changes are documentation-only metadata additions without affecting setting behavior or logic.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Pre-merge checks

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and accurately summarizes the main change—adding version numbers to settings documentation across multiple files.
Description check	✅ Passed	The description is related to the changeset, providing context about the motivation and the specific documentation improvements being made.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b66dc12 and 0aa89fe.

📒 Files selected for processing (2)

• docs/user/admin/settings.rst
• docs/user/ppl/admin/settings.md

🧰 Additional context used

📓 Path-based instructions (1)

docs/**/*.rst

⚙️ CodeRabbit configuration file

docs/**/*.rst: - Verify examples use valid test data and indices

• Check documentation follows existing patterns and structure
• Validate syntax examples are complete and correct
• Ensure code examples are tested and working
• Check for consistent formatting and style

Files:

• docs/user/admin/settings.rst

🧠 Learnings (1)

📚 Learning: 2025-12-11T05:27:39.856Z

Learnt from: LantaoJin
Repo: opensearch-project/sql PR: 0
File: :0-0
Timestamp: 2025-12-11T05:27:39.856Z
Learning: In opensearch-project/sql, for SEMI and ANTI join types in CalciteRelNodeVisitor.java, the `max` option has no effect because these join types only use the left side to filter records based on the existence of matches in the right side. The join results are identical regardless of max value (max=1, max=2, or max=∞). The early return for SEMI/ANTI joins before processing the `max` option is intentional and correct behavior.

Applied to files:

• docs/user/admin/settings.rst
• docs/user/ppl/admin/settings.md

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (27)

• GitHub Check: security-it-linux (25)
• GitHub Check: security-it-linux (21)
• GitHub Check: build-linux (25, unit)
• GitHub Check: build-linux (21, doc)
• GitHub Check: build-linux (21, integration)
• GitHub Check: build-linux (25, doc)
• GitHub Check: build-linux (25, integration)
• GitHub Check: build-linux (21, unit)
• GitHub Check: bwc-tests-full-restart (21)
• GitHub Check: bwc-tests-full-restart (25)
• GitHub Check: bwc-tests-rolling-upgrade (25)
• GitHub Check: bwc-tests-rolling-upgrade (21)
• GitHub Check: build-windows-macos (macos-14, 25, unit)
• GitHub Check: build-windows-macos (macos-14, 21, doc)
• GitHub Check: build-windows-macos (macos-14, 25, doc)
• GitHub Check: build-windows-macos (windows-latest, 21, -PbuildPlatform=windows, unit)
• GitHub Check: build-windows-macos (macos-14, 25, integration)
• GitHub Check: build-windows-macos (windows-latest, 25, -PbuildPlatform=windows, unit)
• GitHub Check: build-windows-macos (macos-14, 21, integration)
• GitHub Check: build-windows-macos (windows-latest, 25, -PbuildPlatform=windows, integration)
• GitHub Check: build-windows-macos (windows-latest, 21, -PbuildPlatform=windows, integration)
• GitHub Check: build-windows-macos (macos-14, 21, unit)
• GitHub Check: security-it-windows-macos (windows-latest, 25)
• GitHub Check: security-it-windows-macos (macos-14, 21)
• GitHub Check: security-it-windows-macos (macos-14, 25)
• GitHub Check: security-it-windows-macos (windows-latest, 21)
• GitHub Check: CodeQL-Scan (java)

🔇 Additional comments (3)

docs/user/ppl/admin/settings.md (1)

6-10: Version metadata structure is clear and consistently formatted.

The markdown file maintains consistent formatting for all version subsections: a level-3 heading (### Version) followed by the version number. This improves discoverability for readers seeking when a setting became available.

Also applies to: 72-76, 113-117, 148-152, 184-188, 222-226, 257-261, 322-326, 399-403, 437-441

docs/user/admin/settings.rst (2)

22-24: Version metadata is properly formatted for reStructuredText standards.

The .rst file uses correct RST section header syntax (Version with dashes underline) for all version entries, maintaining consistent documentation structure. This aligns with the existing RST style conventions.

Also applies to: 88-90, 132-134, 178-180, 210-212, 247-249, 279-281, 304-306, 345-347, 386-388, 423-425, 463-465, 503-505, 544-546, 584-586, 619-621, 658-660, 696-698, 736-738, 820-822, 883-885, 903-905, 919-921, 935-937, 951-953

---

210-212: Remove this review comment - the version format is not a simplification.

Version 3.4 in the Version header was added as major.minor format (not simplified from 3.4.0). All version entries throughout docs/user/admin/settings.rst consistently use major.minor format only: 1.0, 2.12, 2.13, 2.16, 2.17, 2.19, 3.0, 3.1, 3.3, 3.4. Patch versions (X.Y.Z format) appear only in inline documentation text (e.g., "since 3.3.0"), not in Version section headers. This pattern is consistent across both docs/user/admin/settings.rst (RST) and docs/user/ppl/admin/settings.md (markdown), confirming this is the intended and established documentation style.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[LantaoJin]

So you manually checked all commits to identify the introduce versions, did you? I am not sure should reviewer check them again. I approve this changes without checking the specific version values.

[RyanL1997]

Thanks for the change, and I was wondering if there is also a similar way to handle the deprecation of a config?