Publishes the exact allowlisted snapshot from the private Beta 2 development line. Historical platform evidence remains truthful; native Windows and macOS are no longer release gates or support promises. Material AI assistance was reviewed by the maintainer. Signed-off-by: Cole Speelman <crspeelman@gmail.com>
2.5 KiB
Repository verification tools
These scripts are intentionally understandable shell rather than a release framework with hidden defaults. The maintained verification and release path is Linux.
verify.shruns root and nested-module tests and vet, buildshimesan, checks the compiler-owned golden output, and proves two generation passes leave the same bytes and unchanged modification times. SetHIMESAN_RACE=1for race tests.check-licenses.shenforces the AGPL compiler / Apache runtime boundary and prevents generated application Go from inheriting an AGPL identifier.release-check.sh --version vX.Y.Zis a clean-checkout technical preflight, including exact candidate-version and generated-provenance checks. Beta publication follows the narrower prerelease gates inRELEASE.md; release candidates and final v1 additionally use--publicwith a human-reviewedHIMESAN_RELEASE_EVIDENCE_DIR. The script never tags, pushes, publishes, or deploys.verify-public-install.sh --version vX.Y.Zis a post-tag/publication check. It verifies exactgo-get=1package routes, adds the nested runtime before installing the parent compiler, and exercises fresh direct-fetch and public-proxy caches without interactive Git credentials.
The canonical Linux CI and release preflight also run bounded fuzz sessions for the parser/context compiler and Go-aware delimiter scanner. Seed-corpus execution remains part of ordinary go test; the bounded sessions are extra evidence, not a substitute for longer scheduled fuzzing before v1.
The release preflight invokes govulncheck from the official Go vulnerability project at the exact module version golang.org/x/vuln@v1.6.0. Updating that pin requires reviewing the upstream tag and rerunning the supported Go lines.
Preview automation status
Forge workflows are intentionally excluded from the sanitized pre-1.0 public
snapshot. The private development repository uses pinned Linux runners; the
public source remains independently verifiable with verify.sh, the license
check, and the Linux release preflight.
If Gitea automation is later added to the public repository, pin every external action to a reviewed immutable commit, document its provenance, grant minimum permissions, and keep a local verification path. A secondary forge may host a sanitized, read-only discovery snapshot, but hosted workflows stay disabled there and it does not become a release or contribution authority.