chore(release): evaluate promoting qualified pre-release artifacts instead of rebuilding for stable
Maintainer antworten meist innerhalb von 1 Tag
@purp arbeitet bereits daran.
Seit 23.9.2026.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
Description
Decide whether stable releases should publish the exact bytes of the qualified pre-release (promotion) or rebuild the qualified commit with the stable version (rebuild), and what it would take to make promotion possible.
The initial RFC 0014 qualification work (#3559) will rebuild, because every pre-release artifact embeds its pre-release version today. Rebuilding has a cost we want to remove: each stable build is another execution of the full toolchain and dependency graph, and so another opportunity for a supply-chain compromise to enter an artifact that qualification never exercised. Promotion would make the qualified bytes and the published bytes identical.
Context
RFC 0014 does not settle this. Qualification must exercise the pre-release artifacts "rather than a substitute source build" (rfc/0014-release-stability/README.md). Stable publication is described only as "Publish stable artifacts" followed by undefined "Final artifact checks" before the tag is created.
Entanglement with "no version in source." The RFC's version-selection supplement makes Git tags the version source of truth: "release versions are never committed to source." The build therefore injects the version from the tag at build time, and every artifact carries it. For v0.1.0-pre.7:
| Artifact | Embedded version | Where it's injected |
|---|---|---|
Rust binaries (--version) |
0.1.0-pre.7 |
build-rust-binary rewrites version = "0.0.0" in Cargo.toml (tasks/scripts/release.py, _versions_from_prerelease) |
| Default supervisor image tag compiled into binaries | 0.1.0-pre.7 |
release-tag.yml passes supervisor-image-tag: semver |
| Gateway, sandbox, supervisor images | Same as binaries | build-docker-image copies the prebuilt binaries in |
| Deb | 0.1.0~pre.7-1 |
release.py |
| RPM | 0.1.0-0.pre.7 |
release.py |
| Python wheel | 0.1.0rc7 |
SETUPTOOLS_SCM_PRETEND_VERSION |
| Snap | 0.1.0-pre.7 |
release.py |
| Helm chart / app version | 0.1.0-pre.7 |
release-tag.yml chart-version / app-version |
Because the stable tag doesn't exist until the pre-release has qualified, the stable version can't be in any artifact built before that point. Republishing pre-release bytes as stable would ship binaries reporting 0.1.0-pre.7 and defaulting to supervisor:0.1.0-pre.7.
Promotion therefore requires separating "what was compiled" from "what version it's called." Directions to evaluate, not an exhaustive list:
- Version-neutral compiled artifacts, with the version stamped at packaging time (package metadata, image tags, chart version) and discovered at runtime from that metadata.
- Keeping the version out of compiled code while still identifying the build, e.g. by source commit or digest, and mapping that to a release version externally.
- Reproducible builds, so a rebuild can be verified bit-for-bit against the qualified artifact (reduces, but doesn't remove, the rebuild's trust surface).
Related: #3559 (RFC 0014 security qualification).
Definition of Done
- Written comparison of promotion vs. rebuild covering supply-chain exposure, what qualification actually vouches for, and operational cost.
- Inventory of every place a version is compiled into or embedded in a release artifact, and what depends on each (e.g.,
--version, default supervisor image tag, package-manager upgrade ordering). - Assessment of whether the "no version in source" decision can coexist with promotion, and what would have to change if not.
- Recommendation, with follow-up issues if promotion is pursued.
- Vorherrschende Sprache
- Rust
- Sterne
- 8.7k
- Forks
- 1.3k
- Ø Merge
- 1 T. 20 Std.
- Gemergte PRs (30 T.)
- 311
Entwicklungsumgebung
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus NVIDIA/OpenShell
-
area:docs
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
state:triage-needed
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
NVIDIA/OpenShell#3400 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
area:cli state:validated
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
NVIDIA/OpenShell#2888 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
state:triage-needed
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
Maintainer antworten meist innerhalb von 1 Tag
-
area:build spike state:review-ready state:stale
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 68/100
NVIDIA/OpenShell#2401 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in NVIDIA/OpenShell
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 92/100
bytecodealliance/wasmtime#14433 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag