Doc release for version 1.3

[artberger]

Doc issues for 1.3 features

• Docs for ext MCP #609
• Docs for A2A Backends #530
• Doc new grafana dashboard #504
• More agctl commands #582
• Document custom LLM providers #570
• ext proc enhancements
• standalone mode enhancements
• request buffering
• backend TLS enhancements and dynamic SSL certs
• inheritance updates? (existing doc link), possibly related to Clarify shallow policy merge semantics for nested fields #542

Pre-release

• Confirm that the upgrade and release note pages are updated. Typically, this is a separate issue.
• In content/docs, create the new main by making a copy of the current main directory. Rename the directories appropriately. For example, the old main is copied to a new main, the old main becomes latest, and the old latest version gets deleted (agentgateway only maintains n latest and n+1 main in development).
• For the _index.md pages of each version, update the version in the title.
• In the latest version of the content/docs you just copied, update the test paths from main to latest.
  Example search:

  In ./website/content/docs/standalone/latest
  Find file: content/docs/standalone/main/
  Replace with file: content/docs/standalone/latest/
  # and repeat for kubernetes
  

• In the hugo.yaml file, update the versions to include the new minor version as main, the previous main as latest, and the previous latest as its version.
• Update the version conrefs in the assets/docs/versions directory. Often, there is not a release for the next version, so you might have to use the same for latest and main.
• Add the release date to the version table in assets/docs/pages/reference/versions.md, and remove any retired versions.
• Update the version shortcodes to include the newest version. For example, if 2.2.x is the latest release, search for version include-if="2.1.x" to add version include-if="2.2.x,2.1.x". Keep in mind that the include-if might start with different versions, like include-if="2.0.x,2.1.x,2.2.x" so do a few searches.
  • Example find and replacements for a hypothetical 2.8 release
    1. "2.8.x, > "2.9.x,2.8.x,
    2. ,2.8.x" > ,2.8.x,2.9.x"
    3. "2.8.x" > "2.9.x,2.8.x"
    4. "2.4.x, > "
    5. ,2.4.x" > "
    6. Delete any content that is in "2.4.x" only tags (older than n-3)
    7. For anything that is now in "2.9.x,2.8.x,2.7.x,2.6.x,2.5.x" or "2.5.x,2.6.x,2.7.x,2.8.x,2.9.x" tags, keep the content but delete the version tags surrounding it
• Search content for any hard-coded instances of the version, like 2.1, as well as any retired versions, and update if needed. Example pages are upgrade, version skew, and reference pages.
• Generate reference docs for the new version.

Post-release

• Merge in the autogenerated PR that the workflow created
• Verify that the docs are published
• Cut a GitHub release of the docs repo for the new release, and include any retired version (such as Release for 2.6.x and last state for retired 2.2.x)
• If maintaining a downstream version, update the content paths for the new version.