Restructure prerelease status.json tree: prerelease/ + group by major.minor

[HereThereBeDragons]

Summary

Following the RFC and release_type in TheRock, we restructure the prerelease
status.json tree. Two changes:

1. Rename the top folder prereleases/ → prerelease/, matching
   release_type and the RFC.
2. Group prereleases by major.minor. With patch releases now in scope, the
   tree becomes prerelease/<major.minor>/<full>/status.json, e.g.
   prerelease/7.14/7.14.0rc1/status.json and prerelease/7.14/7.14.1rc1/....
   Every patch of one release line lives under a single directory.

Pointers

Two latest.json symlinks are maintained, both version-key ordered so they never
regress (e.g. rc10 → rc2):

• prerelease/latest.json — highest-versioned candidate across all release lines.
• prerelease/<major.minor>/latest.json — highest-versioned candidate within one
  line.

Both are updated in O(1) when a new status.json is written: we point at the
just-written file and compare only against the current symlink target, with no
directory scan and a no-regress guard.

Notes

No prerelease build is published yet, so no on-disk migration or later
renaming/deletion is needed.

[marbre]

Suggested change

	| `prerelease/<base>/<full>/status.json` | A specific prerelease, for example `prerelease/7.14.0/7.14.0rc1/status.json` |
	| `prerelease/<base>/<full>/status.json` | A specific prerelease, for example `prerelease/7.14.0/7.14.0rc1/status.json` |

[marbre]

As you're iterating here anyway, why is it "7.14.0" / "7.14.0rc1" and not "7.14.0" / "rc1", "7.14.0" / "1" or even simply "7.14.0rc1"?

Or rather I assume we have a different folder structure here compared to stable releases or eventually nightlies. What's the rational behind?

[HereThereBeDragons]

just thought it would be nicer to group them. but maybe now that we have patch releases top level should be "7.14"

and then you could have: "7.14" / "7.14.0rc2" and "7.14" / "7.14.1rc1"

what do you think?

[marbre]

I don't have a too strong feeling but from restructuring repo.amd.com I learned you don't want to have too many special cases and rather want to harmonized over the different release streams. The suggestion on its own however looks good.

[cgoea]

My take, let's do it now. Everything is ready and it should be a simple change.

[cgoea]

Following RFC and release_type in TheRock, rename prereleases/ top folder to prerelease/

No prerelease build is published yet, so no renaming/deletion at a later point needed.

Maybe it would be the time to bump the schema version.

[HereThereBeDragons]

Maybe it would be the time to bump the schema version.

i think i would rather put this after #93 is merged.

and in addition i would like to have the following schema changes first:

• document pytorch_enabled/jax_enabled needs to be put in the status reference json ( fix: track expected pipelines correctly #88 missed that)
• list the sha from therock also in the schema
• list build_variant in the schema (for future asan vs release)

both commit sha and build_variant can be extract from setup.yml

[marbre]

Maybe it would be the time to bump the schema version.

i think i would rather put this after #93 is merged.

and in addition i would like to have the following schema changes first:

• document pytorch_enabled/jax_enabled needs to be put in the status reference json ( fix: track expected pipelines correctly #88 missed that)
• list the sha from therock also in the schema
• list build_variant in the schema (for future asan vs release)

both commit sha and build_variant can be extract from setup.yml

It is valid to pull it as a package that than justified the version bump. However, the question is when to raise the number. Maybe the development model needs an adjustment here and you want to work on a feature branch and merge it all at once into develop. As far as I remember every commit is mirrored directly to main and thus it otherwise all lands incrementally.

[HereThereBeDragons]

It is valid to pull it as a package that than justified the version bump. However, the question is when to raise the number. Maybe the development model needs an adjustment here and you want to work on a feature branch and merge it all at once into develop. As far as I remember every commit is mirrored directly to main and thus it otherwise all lands incrementally.

as we already got some changes in main i guess the ship has sailed this time. but agree next time we need a proper strategy how to add new features but enable them only when a version bump arrives