Rendering now resolves every refs number through the GitHub GraphQL API.
A pull request gains "by @author". An issue gains "fixed in #M by @author"
for each merged pull request GitHub links as closing it (the ClosedEvent
closer and closedByPullRequestsReferences; mentions are not fixes); an
issue fixed by a direct push stays plain. Bot authors are never credited.
A number that names a discussion or nothing stays plain with a warning.
The closing Contributors / 贡献者 section lists exactly the credited
humans, once each, in first-appearance order. It replaces the old Thanks
section, which linked the catalog's contributors (github-actions[bot]
included) without mentioning them; that field no longer feeds the notes.
Lookups are cached per run, bounded in concurrency, and retried with
backoff on 5xx, rate limits and dropped connections. A failure that
persists, or an authorisation failure, renders the ref as its plain link
and fails the command with a release_credits.* code.
Because rendering now reads GitHub, the seal job renders the notes once
into the candidate payload (evidence/release-notes.md, recorded as
notes.renderedPath and bound to renderedSha256). Promotion publishes
those sealed bytes with no network call, so a rename, a newly linked fix
or an outage after sealing cannot change or block the release. Candidates
sealed before this carry no renderedPath and render offline as before.
Every job that renders, and every caller of a reusable workflow that
does, gains issues: read and pull-requests: read.
Problem:
The legacy compatibility path could let manually authored v1.31.4 and newer records bypass per-client target metadata.
Root cause:
Validation required item targets only when targetingVersion was already present, without an adoption boundary for future releases.
Fix:
- require targetingVersion 1 for v1.31.4 and newer core versions
- preserve legacy rendering and validation for older releases
- cover the adoption boundary across stable and preview versions
Verification:
- node scripts/release-notes.mjs validate
- node --test scripts/release-notes.test.mjs
- bash scripts/release-workflows.test.sh
- node scripts/check-single-release-public-contract.mjs
- git diff --check
Problem:
Release notes combine Desktop and CLI changes, so users cannot tell which client needs an update.
Root cause:
The release ledger has no item-level target metadata, and every renderer flattens the same product-wide sections.
Fix:
- add versioned Desktop, CLI, site, and service targets with strict validation
- derive target hints from pull request labels and changed paths
- render client-specific sections across GitHub notes, the website, and built-in docs
- preserve the legacy layout for historical releases
Verification:
- node scripts/release-notes.mjs validate
- node --test scripts/release-notes.test.mjs
- go test ./internal/productdocs
- cd site && npm test
- go test ./...
- cd site && npm run build
- bash scripts/release-workflows.test.sh
- node scripts/check-single-release-public-contract.mjs
- actionlint release workflows
- go run ./tools/repolint
Refs #9394
Context: Stable and Preview need independent reviewed identities while CLI, Desktop, npm, and changelog publication remain one protected release event.
Changes:
- Add a protected Preview orchestrator with a shared ordinal and SignPath preflight.
- Bind reviewed release notes to immutable all-surface publication markers.
- Route downloads and changelog archives by channel with accessible theme-aware navigation.
- Harden release authorization, manifests, tests, and operator documentation.
Compatibility:
- Legacy catalog entries without managed status remain readable and public.
- Existing Stable pointers remain unchanged, and Preview continues mirroring the legacy canary pointer for older Desktop clients.
- No persisted user state or Wails JSON contract changes.
Verification:
- bash scripts/release-workflows.test.sh
- node --test scripts/release-notes.test.mjs
- cd desktop && go test ./cmd/sign ./internal/update
- cd site && npm test
- cd site && npm run build
- actionlint for all release workflows
Problem:
Release notes were assembled independently from commit-oriented GitHub output, leaving the website, desktop updater, and CLI/Desktop releases without one reviewed product narrative.
Root cause:
There was no structured bilingual release catalog or review workflow shared by the site, desktop UI, and tag publishers.
Fix:
Add a validated release catalog and DeepSeek-assisted draft workflow, publish responsive website changelog pages with shared navigation, link Desktop update surfaces to the web history, and render the reviewed notes into CLI and Desktop GitHub releases.
Verification:
- node scripts/release-notes.mjs validate
- node --test scripts/release-notes.test.mjs
- npm test and Astro build in site/
- pnpm run build in desktop/frontend/
- actionlint for all affected workflows
- git diff --check
Cache-impact: none - release metadata, website UI, desktop links, and publication workflows do not change provider-visible prompts, tool schemas, request serialization, or ordering.
Cache-guard: existing scripts/cache-guard.sh remains applicable; no cache-sensitive path changed.
esengine