build(pytorch) [Release 7.14] Remove pytorch 2.9 + nightly

[HereThereBeDragons]

Adjust pytorch build matrix matching 7.14 release matrix.
Drops building pytorch 2.9 and nightly

[ScottTodd]

Do we actually need this? I'd prefer to keep changes on the release branches minimal. Without this change we'll build more packages than we publish and I think our package promotion scripts already handle that?

[ScottTodd]

With the more recent code on the main branch we could choose to drop nightly if the release_type is prerelease, see

TheRock/build_tools/github_actions/configure_pytorch_release_matrix.py

Lines 29 to 51 in a13cf65

	# TODO: separate out "nightly" pytorch refs from "prerelease" pytorch refs?
	# That would let us:
	# 1. choose to not build the "nightly" pytorch branch for prerelease builds,
	# saving some CI resources and possibly simplifying package promotion
	# scripts.
	# 2. filter out some AMDGPU families from prereleases if we only want them
	# built for nightly but not published to stable.
	RELEASE_PYTORCH_REFS = {
	"linux": [
	"release/2.9",
	"release/2.10",
	"release/2.11",
	"release/2.12",
	"nightly",
	],
	"windows": [
	"release/2.9",
	"release/2.10",
	"release/2.11",
	"release/2.12",
	"nightly",
	],
	}

[HereThereBeDragons]

agree that would be a good change on main.

[ScottTodd]

If we're dropping support for the pytorch release/2.9 branch, shouldn't we also do that on TheRock's main branch for nightly releases too? Why just for TheRock's release/7.14 branch?

[HereThereBeDragons]

yes we should. i havent heard any resistant against it since i proposed this to lockstep this with the release.

[HereThereBeDragons]

Do we actually need this? I'd prefer to keep changes on the release branches minimal. Without this change we'll build more packages than we publish and I think our package promotion scripts already handle that?

i would argue the less people need to think about what we are triggering in the release, the better. if we manage to have this more automated and dont need so many changes on the release branch thats of course preferred but currently we are not there yet.

for the download script yes you can have include and exclude globs, for promotion just include glob.
however also for accountability in the future and reducing confusion i think it would be better to just build what we want and not build everything and then select.

one more thought:
maybe in the future we immediately drop the old versions we no longer want to support on main before the branch cut and then just have the exception "if release skip nightly"

[ScottTodd]

Do we actually need this? I'd prefer to keep changes on the release branches minimal. Without this change we'll build more packages than we publish and I think our package promotion scripts already handle that?

i would argue the less people need to think about what we are triggering in the release, the better. if we manage to have this more automated and dont need so many changes on the release branch thats of course preferred but currently we are not there yet.

Agreed. Alright, I'm fine with this change then.