CUDA update policy

[atalman]

Supersedes #74.

Same goal as #74 — write down the CUDA update policy the PyTorch team follows — with two changes based on review feedback.

1. Policy only; the upgrade runbook is dropped from the RFC

#74 also inlined the CUDA/cuDNN Upgrade Runbook consolidated from pytorch/builder. Those steps reference specific PRs, scripts and versions and change on every upgrade, while the RFC should be stable policy. They also duplicated a CUDA/cuDNN support table that is already maintained (and is current) in RELEASE.md. The runbook content is unchanged and preserved in #74; it should land as a runbook next to the CI/CD scripts it describes.

A new Relationship to RELEASE.md and the upgrade runbook section states the split:

• this RFC — policy (introduction/deprecation criteria, Legacy/Stable/Experimental categories, release gates);
• pytorch/pytorch RELEASE.md — the per-release record and release mechanics (Release Compatibility Matrix, PyTorch CUDA Support Matrix, Accelerator Software, Drafting RCs, Modify release matrix);
• runbook — the mechanical upgrade steps.

This mirrors CPython support, where RELEASE.md's Python section links out to RFC-0038. RELEASE.md's Accelerator Software section should get the same link to this RFC (follow-up PR in pytorch/pytorch).

2. CI, not CD, is the gate for shipping a CUDA version

#74 said:

3. Update CUDA in CD (this is necessary condition to qualify for CUDA version be released as Experimental)

and defined the Experimental version as qualifying once it is "available in nightly releases (CD)". That is wrong: it makes buildable-in-nightly sufficient to ship, i.e. we could release a version nobody tested. Two principles are now stated explicitly and take precedence over the individual steps:

1. We do not release anything that is not tested in CI. CD-only enablement produces binaries nobody has validated. A version qualifies for a release (including as Experimental) only once it has CI build and test coverage with failures tracked.
2. We do not cut an RC for anything we are not planning to promote. The release matrix is decided before branch cut and only those versions are built in the RC.

Resulting changes to the process:

• the Experimental definition now requires CD builds and CI build/test coverage, with failures triaged before branch cut;
• step 3 (CD) is demoted to a prerequisite for CI enablement, explicitly not a release qualification;
• step 4 (CI) carries the Experimental qualification;
• step 5 (benchmarks) is gated on CI being complete, not CD;
• new step 6 fixes the release matrix before branch cut and restricts RC builds to it;
• deprecation step 2 keeps "drop CD before CI" and says why: we never ship a version we have stopped testing.

Also fixed: the step-1 self-link pointed at the cuda_update branch (would break once merged), the Windes typo, and a reference to conda platforms we no longer publish.

Related RFCs for CUDA update:
pytorch/pytorch#147383
pytorch/pytorch#145544
pytorch/pytorch#138609
pytorch/pytorch#134015

[albanD]

Mostly ok, just one small comment.

[albanD]

I'm surprised about this ordering? CI doesn't actually consume the CD result?
We could enable build + test in CI first. And then once good, enable CD ?

[atalman]

Hi @albanD normally we do CD first since CD just builds binaries, followed up by CI which take considerably more time. Basically CD is build, CI is build+test. Resolving issues for CD help us to prepare for CI build and test. Since we would have caught the same issues in CI if we would start with CI first.

[atalman]

Made some changes f8cd77b

[albanD]

Ok!