post(TRI-1872): advance main to 26.09 upstreams

[mc-nv]

What does the PR do?

Advances main to build against the 26.09 upstream containers.

• Cherry-picks docs: Add 26.09 vllm-python-py3 and ONNX Runtime versions to compatibility matrix (#8986).
• Bumps build.py upstream_container_version 26.08 -> 26.09.
• Text-replaces 26.08 -> 26.09 across README/deploy/docs/qa references.
• Bumps released semver 2.72.0 -> 2.73.0 in the 7 version-carrying files
  (README warning banner, gke/fleetcommand chart manifests).

Checklist

• PR title reflects the change and is of format <commit_type>: <Title>
• Changes are described in the pull request.
• Related issues are referenced.
• Populated github labels field
• Added test plan and verified test passes.
• Verified that the PR passes existing CI.
• Verified copyright is correct on all changed files.
• Added succinct git squash message before merging.
• All template sections are filled out.

Commit Type:

• build

Related PRs:

• post: advance main to 26.09 upstreams client#933
• chore(doc,versions): Update README and Versions for 26.09 tutorials#173

Where should the reviewer start?

build.py's DEFAULT_TRITON_VERSION_MAP and README.md's [!WARNING]
banner.

Test plan:

• pre-commit run on changed files passed.
• python3 -c "import ast; ast.parse(open('build.py').read())" passed.
• All touched YAML parsed with PyYAML.
• git grep -n "26.08" confirmed only legitimate historical survivors
  remain (compatibility.md rows, stale qa/ examples unchanged on r26.09
  itself).

Caveats:

release_version/triton_container_version in build.py and
TRITON_VERSION were deliberately left untouched — they're already on the
next dev train (2.74.0dev / 26.10dev) from an earlier code-freeze step.

Background

Part of the post-26.09-release "advance default branches" step
(triton-release-post-advance-default-branches skill).

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• Resolves: TRI-1872

[greptile-apps]

Confidence Score: 4/5

[High risk] Updates container image versions across deployment and build configuration.

The PR appears safe to merge, with three non-blocking version-consistency and documentation fixes recommended.

Findings

1.  Release notes link stays outdated ▶
2.  QA fallback remains on 26.08 ▶
3.  Chart version stays unchanged ▶

Summary

This PR advances default upstream containers, deployment examples, and QA image selection to 26.09 while updating published-release references to 2.73.0.

• The release-notes link still targets 26.08.
• The QA generator’s fallback upstream version and Fleet Command chart version were not advanced with their corresponding defaults.

_{Reviews (1) · Last reviewed commit: "post(TRI-1872): advance main to 26.09 up..."}

[greptile-apps]

Release notes link stays outdated The heading says 26.09, but the link still opens the 26.08 release notes. Readers looking for 26.09 changes will get the previous release’s notes.

[greptile-apps]

QA fallback remains on 26.08 This changes the default upstream image to 26.09, but the QA model generator’s fallback is still 26.08. If the generator cannot read build.py, it uses 26.08 for its PyTorch and TensorRT image tags and records the wrong upstream version in manifests.

Knowledge Base Used: Quality assurance and integration coverage

[greptile-apps]

Chart version stays unchanged The app version and default image advance to the new release, but the chart remains at 1.4.0. This conflicts with the versioning policy in Chart.yaml; a newly packaged chart would still have the same chart version as the preceding package, making the releases harder to distinguish.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!