Repository navigation
Gate v1 publication on package and stable-Core qualification #5
Description
Production v1 publication must qualify the exact wheel/sdist files that are later published.
Required release gate:
- Freeze the source commit and require the supported normal/optimized/static/differential checks.
- Build the wheel and sdist once and install those exact artifacts in isolated supported Python/OS environments.
- Run the installed release wheel against official stable Bitcoin Core v32 binaries.
- Retain source commit, package hashes and Core version; publish only the qualified files.
Current split, requested by the maintainer:
- release: Qualify packages before publishing #52 contains the mergeable-without-stable-binaries portion: successful source-CI prerequisite, build-once package qualification, hashes/source record, correct prerelease handling, and publication of those same bytes. Duplicated source CI and RC-specific release machinery were removed.
- release: Qualify built packages with stable Core v32 #207 tracks the stable-Core release job and making it a required publication dependency. core: Pin fixtures and tutorials to stable v32.1 #164 supplies the fixture/tutorial stable pin once official binaries are published.
- Until release: Qualify built packages with stable Core v32 #207 is complete, release: Qualify packages before publishing #52 permits only prerelease publication. Stable-version tags may build/test but cannot publish. The existing pypi environment has no approval protection rules, so it is not itself a manual gate.
Keep this issue open through human integration, #207 completion, and successful qualification/publication of the final frozen candidate. Merging #52 alone does not authorize or enable stable v1 publication.
Activity
BenWestgate commentedon Sep 25, 2026
Bitcoin Core release monitor (2026-09-25): 32.0 is still in RC; the official
bitcoin-core-32.0/index currently contains onlytest.rc2/, and the public download page lists 31.1 as latest stable. Release qualification should therefore treat PR #51's 32.0rc2 run as pre-final evidence, not the final v1 Core qualification. When a newer RC/final appears, repin and rerun before publication.When stable Bitcoin Core 32.0 is released, also clean up BenWestgate/Bails#244: remove the now-dead 32.0rc2 fallback (
VER=32.0rc2/bitcoin-core-32.0/test.rc2) after confirming Bails follows the normal stable-release path.BenWestgate commentedon Sep 27, 2026
Bitcoin Core release monitor refresh (2026-09-26): upstream
bitcoin/bitcoinstill exposesv32.0rc1andv32.0rc2under thev32.0tag namespace, with no finalv32.0tag. Keep #51/#52 pinned to rc2 as pre-final evidence; repin and rerun both the fixture gate and exact-artifact qualification if rc3 or final appears before publication.BenWestgate commentedon Sep 28, 2026
Bitcoin Core release monitor refresh (2026-09-28): upstream still has
v32.0rc2;refs/tags/v32.0rc3and the finalv32.0release are absent. Keep #51/#52 pinned to rc2 as pre-final evidence only. If rc3 or final appears before publication, repin the pinned archive/hash and rerun both the real-Core fixture gate and exact-artifact release qualification.BenWestgate commentedon Oct 1, 2026
Bitcoin Core release monitor refresh (2026-10-01): upstream
bitcoin/bitcoinstill exposes onlyv32.0rc1andv32.0rc2under thev32tag prefix; there is nov32.0rc3or finalv32.0tag. Keep #51/#52 pinned to rc2 as pre-final evidence only. If a newer signed RC or final appears before publication, repin the archive/hash and rerun both the real-Core fixture gate and exact-artifact release qualification.Gate release on exact artifacts
release: Qualify packages before publishing
release: Keep package qualification focused
[-]Gate v1 publication on final-RC integration and built-artifact verification[/-][+]Gate v1 publication on package and stable-Core qualification[/+]