server-monitor-manager/docs/release-policy.md

Release policy

Published tags and release assets are immutable.

A tag that has been published must never be moved, reused, deleted and recreated, or supplied with replacement assets under the same names. If a published build or installer is wrong, preserve the existing release and publish a new, higher version tag containing the correction.

.github/workflows/linux-release.yml is the sole GitHub Release publisher. On a version tag, it builds the Linux and Windows packages from the tagged commit, generates the signed manifest, and publishes the complete release asset set. .github/workflows/windows-release.yml is manual-only and may package and verify a Windows installer as a workflow artifact, but it never publishes or replaces GitHub Release assets. The tracked production source for the convenience installer is deploy/smm-setup.sh; the Linux release workflow copies that exact file to the release artifact set, records its SHA-256 in the signed manifest, and publishes its standalone checksum. The default release in that source must match the tag being produced.

For v0.1.0-alpha.9, this makes smm-setup.sh, smm-setup.sh.sha256, the bootstrap script, platform archives, SBOMs, and the signed manifest reproducible from the tagged tree. The installer fetches only same-tag assets and verifies the bootstrap checksum before execution. Corrections after publication require another tag; the v0.1.0-alpha.9 tag and assets remain unchanged.

Known release history:

• v0.1.0-alpha.8 contains the v1 server-monitor-manager-bootstrap-manifest.json layout and an orphaned server-monitor-manager-manifest.sig without the corresponding manifest v2. Published assets remain immutable; the anomaly is documented rather than repaired in place.
• v0.1.0-alpha.10 exists as a tag, but its Release pipeline failed before a GitHub Release was published. The version number is burned and must not be moved, deleted, recreated, or reused.
• v0.1.0-alpha.11 exists as a tag, but its Release pipeline failed before a GitHub Release was published. The version number is burned and must not be moved, deleted, recreated, or reused.
• v0.1.0-alpha.12 was published with a keyless manifest signature but without the Fulcio signing certificate, so consumers cannot verify that signature. Its Windows SHA256SUMS asset also used CRLF and was not consumable by GNU sha256sum -c. The immutable release remains published as historical evidence; neither defect is repaired in place.
• v0.1.0-alpha.13 corrected the checksum portability defect, but it was also published with a keyless manifest signature and without the Fulcio signing certificate required by production consumers. The immutable release remains published as historical evidence; the producer/consumer certificate contract is corrected under a higher version.
• v0.1.0-alpha.14 is the first release with the complete manifest, keyless signature, and Fulcio certificate set, so its published assets can be verified. A clean host cannot install it because the release does not provision cosign. Preserve it for verification and historical evidence; do not use it for installation.
• v0.1.0-alpha.15 is the first release that provisions a pinned, checksum-verified cosign binary. Its automatically triggered Release Verification proved the clean-host Hub installation and manifest verification, then stopped before the clean-host Node installation because the acceptance script retained the deliberately removed cosign path in Bash's command hash. The immutable release and failed verification remain as evidence; the acceptance harness is corrected in the next version.
• v0.1.0-alpha.16 clears the acceptance shell's command hash after removing its test-provisioned cosign. Its automatic verification proved clean-host Hub installation, but the convenience installer wrote the bootstrap checksum success line to stdout before the machine-readable SMMNODE2 enrollment code. Node installation therefore rejected the contaminated value. The immutable release and failed verification remain as evidence; stdout isolation is corrected in the next version.
• v0.1.0-alpha.17 keeps checksum verification fail-closed while suppressing its success line, so pass-through commands such as node-code return only their machine-readable bootstrap output. Its automatic verification completed the clean-host Hub and Node installation, then the negative-test harness stopped while creating a wrong-identity signature because cosign v3 requires an explicit bundle or legacy detached-output mode. The immutable release and failed harness run remain as evidence; the negative test is corrected in the next version.
• v0.1.0-alpha.18 makes the wrong-identity negative test select cosign v3's explicit detached-output mode, matching the production consumer's detached signature and certificate contract. It is the first release required to complete both automatic workflow_run verification and manual workflow_dispatch re-verification.
• v0.1.0-alpha.19 exists as a tag, but its Release pipeline failed when the packaged convenience installer's DEFAULT_RELEASE_TAG did not match the immutable tag. No GitHub Release was published. The version number is burned and must not be moved, deleted, recreated, or reused.
• v0.1.0-alpha.20 matches the packaged convenience installer's DEFAULT_RELEASE_TAG to the tag being produced, which is the defect that burned v0.1.0-alpha.19. It also adds a pipeline step that tests the latest published release before a new one is cut. It carries the content that v0.1.0-alpha.19 failed to publish: the operator web console, the guided unified installer, the complete uninstall mode, the node enrollment endpoint, and the mesh state permission fix.

Every release candidate must pass a branch workflow_dispatch run of the Release pipeline before its immutable version tag is created. The release owner has sole write ownership of version sources, deploy/**, tests/bootstrap/**, release workflows, the root README release status, and translated README release statuses. Other contributors request changes to those paths in their report; they do not edit or bump them directly. One pull request covers one release topic and may merge only after required CI is green.