Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

chore(release): evaluate promoting qualified pre-release artifacts instead of rebuilding for stable

Aberta
  • Algo errado?
#3,632 1 comentário 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@purp já está trabalhando nisso.

Desde 23/9/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

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.
Linguagem predominante
Rust
Estrelas
8.7k
Forks
1.3k
Merge médio
1d 21h
PRs com merge (30d)
344

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de NVIDIA/OpenShell

Todas as issues de NVIDIA/OpenShell

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.