Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Synapse 1.5.0 release preparation

Tracking: SYN-340 (#343). Status at the original preparation freeze: source preparation only. The sections below preserve that historical evidence and its then-pending gates. The later publication outcome follows here.

Actual publication outcome

After reviewed source and CI gates, annotated v1.5.0 selected merged commit b86833767bcc3fa726dd60cfb19fe5d9d8036a07. Source workflow 39095566496 built all four platforms and published seven signed assets. Mirror workflow 39096975503 preserved them in the public release.

The independent npm consumer then rejected the Windows archive’s changelog: checkout conversion produced CRLF bytes that differed from the exact committed source digest. Publication stopped before publishing any npm package. This does not invalidate the manifest signature or authorize normalizing consumer inputs. SYN-343 (#348) tracks canonical document packaging and the forward 1.5.1 correction. The existing 1.5.0 tag and assets are retained unchanged. These actual outcomes do not retroactively change the scope of the historical preparation evidence.

Candidate scope

v1.4.0 is 73 commits behind source baseline 21242ae0c2a2d592dedad439631ecc8e0a97df1e. The generated candidate adds the bounded versioned knowledge process contract and guarded review decisions, Memory CI, scoped diagnostics, explicit revision adapters and source-impact proposals, portable authority evidence, historical shared admissions and native state attestations. These are additive capabilities; guarded writes retain their review and authorization prerequisites. Nothing here claims that all stored knowledge is true or that advisory output grants write authority.

Cached git-cliff 2.12.0 independently recommends v1.5.0. The range contains no ! or BREAKING CHANGE marker. That inspection supports the minor candidate but does not replace API compatibility review. Cargo.toml and the root Cargo.lock package are prepared as 1.5.0. The generated changelog retains the historical 1.4.0 and earlier sections. Its date is the UTC preparation date, not a claim that publication occurred.

Final integration and validation

  1. SYN-339 PR #344 merged as a86212b518387138e1e3634ac7518c4667e38c40. Its required source checks, including Rust 1.89 and native contracts, passed; optional Pages deployment was skipped. Those checks apply to SYN-339, not a compiled 1.5.0 candidate.
  2. This preparation integrated that main commit through 14673ae. The manifest and 590-package lockfile equal merged main except for the root 1.5.0 version. The candidate section was regenerated once from the resulting 82-commit range after v1.4.0, including SYN-339 and SYN-340. Historical 1.4.0 and earlier sections retain their exact bytes. Final source review remains required.
  3. Run the actual release-validator controls, formatting, full Rust tests, production feature compilation, native contracts, dependency policy, docs and MSRV on that final source. Do not reuse an older binary as release proof.
  4. Require independent review of the workflow permissions, exact tag/source selection, source/notes receipt and retained platform/feature restrictions.
  5. The user’s existing authorization covers keeping releases updated after the actual review and validation gates pass. Create the final version tag on that reviewed source commit. The release workflow validates the real tag and committed notes before the four native platform builds. A manual retry must select that existing tag; it cannot publish a branch.

After the required gates and tag creation, an explicit retry uses the tagged workflow:

gh workflow run release.yml --ref v1.5.0 -f tag=v1.5.0

Selecting main as the dispatch ref is rejected even when its tag input is valid: checkout does not change the OIDC workflow identity, which must remain the exact tagged release workflow used by signature verification. This example is an operator procedure, not a command executed during preparation.

The preparation command used the installed tool, without installation or a new Rust target directory:

git cliff --bumped-version --offline --no-exec
git cliff --unreleased --tag v1.5.0 --prepend CHANGELOG.md --offline --no-exec
python3 scripts/check-release-tests.py -v
python3 scripts/check-release-independent-tests.py -v
git diff --check

--tag here supplies a virtual changelog context and creates no Git tag. Do not prepend the same version twice when regenerating: replace its generated section while retaining the historical sections. The original 20 omitted messages, and 21 after integration, are merge prose outside Conventional Commit syntax; feature/fix commits remain listed.

Actual limits

Preparation ran locked offline Cargo metadata, without compiling or creating a target directory, and no Xcode or native platform build. It proves no published signature. The validator’s private Git tags and synthetic archive bytes are test fixtures, not product releases. Actual cosign verification and all four native matrix builds remain release gates. Linux archives require modern glibc and libstdc++; Intel macOS, OS signing/notarization and generic musl compatibility are not supplied. The mirror preserves the original signing identity and refuses existing releases; owner-level GitHub changes remain possible.

Local verification receipt

The actual validator CLI passed 13 unittest methods using private committed Git fixtures, private test tags and synthetic asset bytes. Controls reject wrong tag or commit, dirty inputs, inconsistent manifest/lock versions, duplicate or wrong changelog sections, changed source receipts/notes, branch-based signing identity, missing/extra/symlink archives, duplicate originating archive basenames, changed archive hashes and attempted overwrite. The originating-run receipt selects its tag even when branch environment values say main. A synthetic breaking Conventional Commit rendered the BREAKING marker through the installed generator without changing Git history.

Read-only live GitHub controls establish the CLI’s actual API behavior: an absent synthetic release tag returned validation exit 0; existing v1.4.0 returned 1. No release object was created, edited or deleted. PyYAML and actionlint are not installed; Ruby Psych parsed all three changed workflow files, and bash -n parsed 13 workflow shell blocks after expression substitution. These are syntax checks, not GitHub Actions execution or schema acceptance.

The allowlisted receipt records exits and source/log hashes. Local raw controls remain in /tmp/syn340-release-preparation-20261017. Source CI, MSRV, four native builds, actual signature production/verification and publication remain pending. Legacy workflow runs and old tags retain their old workflow definitions; do not rerun the old publication pipeline as a substitute for this reviewed candidate.

The added staging control initially had a misplaced fixture block and failed with FileExistsError, before its intended checks completed. That setup error is retained as staging-fixture-setup-error.log, separately from the restored 13-method pass; it is not a release-validator regression or assertion RED.

Independent originating HEAD correction

The independently frozen workflow tests from cc02d5f reproduced a real assertion failure: a receipt naming valid source commit A was selected even though the authenticated originating workflow_run.head_sha named B. Artifact download by run ID alone did not establish that commit relationship. This was a trigger/source binding defect, not a signature forgery; original cosign verification still protected authenticated artifact bytes.

The exact failing test was adopted unchanged and its RED retained under /tmp/syn340-origin-head-binding-20261017. Automatic selection now passes the authenticated event HEAD to select --expected-commit, and compares it with the receipt before writing any tag output. Manual tag selection remains separate. The restored gate passes the original 13 validator methods and all nine actual workflow-shell methods, using recording gh/cosign/cargo executables. No real Cargo build, signature operation or publication is supplied by those fixtures. CI now invokes both scripts. The original independent mutation campaign and earlier invalid fixture evidence remain separate from this corrected run.

Existing authorization covers the release update after actual source review, CI/MSRV and platform/signature gates; these records do not add another generic permission step or claim that publication has occurred.

Producer and downstream compatibility follow-up

The original unmodified macOS tar command produced ten members in an owned local fixture because of AppleDouble host metadata. Its initial five-member fixture precondition failed, so that attempt is invalid compatibility evidence, not a product assertion RED. The unchanged actual packaging-shell regression separately failed its observed COPYFILE_DISABLE assertion. Setting that variable to 1 produces the five declared members without weakening downstream selection. The complete validator and workflow-shell suites now pass 13 and 10 methods.

SYN-341 hardens the public npm publication boundary and has independent archive identity and CI-admission corrections. Its reviewed public-repository merge and checks are required before creating the next product tag. The original source receipts remain historical; this follow-up requires exact new-head CI.