Publish changelog-driven release notes #64

New Issue

2026-09-10T07:28:01Z

xavierk commented

2026-09-10 07:28:01 +00:00

Parent

Implement dashboard clarity and release notes

What to build

Turn change notes into a working Release surface: maintainers record user-facing changes, release automation extracts the selected version, and consumers receive those notes together with standing installation, verification, and rollback guidance. Re-running release automation resynchronizes notes without duplicating uploaded assets. Deliver the entire authoring-to-release-body path, its tests, a scripted dispatch verification, and the README release-notes pointer.

Acceptance criteria

DC-6: Adopt Keep a Changelog 1.1 shape. Keep ## [Unreleased] at the top even when empty. Version headings use bracketed bare semver and a strict ISO date. Permit Added, Changed, and Fixed categories only, with security fixes under Fixed; entries are single imperative, user-facing bullets without commit hashes or issue numbers.
DC-7: A checked-in, unit-tested extractor accepts a changelog path and requested version and returns that version's section verbatim. Never fall back to Unreleased. Missing or empty sections and malformed dates emit ::error:: and exit nonzero.
The release workflow fails closed on a pushed tag that differs from v plus the project version. Skip only this tag guard on manual dispatch; section and date validation still apply. Validation failures prevent publication rather than producing a release without notes.
DC-8: Assemble the release body from the extracted version section verbatim plus a separate standing footer containing channel install one-liners, checksum verification, and a rollback pointer consistent with the existing packaging contract. Only the selected changelog section varies per version.
On rerun against an existing release, PATCH the body. Preserve current idempotent-skip behavior for uploaded assets and packages. Keep unrelated packaging, signing, and collector behavior unchanged.
Use the new pure-function extractor seam to test successful exact slices and fail-closed cases. Exercise its command boundary for diagnostics and exit status. Use existing release dry-run prior art for wiring checks; verify body assembly and create-versus-PATCH decisions with observable outputs or captured requests, not source-text checks alone. Automated tests require no production credentials or registry writes.
Record one scripted manual-dispatch verification of body assembly as DC-8 probe evidence, separate from automated unit evidence. Use an authorized test target/ref and document the resulting release body; do not count a dry run as the live probe or silently claim a blocked probe passed.
Document and support release discipline: entries land with each fixing change; one release commit bumps project version, renames Unreleased to the version heading, restores an empty Unreleased section, and is the commit tagged. No historical release backfill; initialize with empty Unreleased and record this mechanism and subsequent changes there.
Incorporate any user-facing entries supplied with sibling slices before the changelog convention landed. Do not delay a completed sibling slice solely for this infrastructure, and do not omit those entries from the first applicable Release.
Add the locked README release-notes pointer, coordinating the shared “Reading the dashboard” section with its other owners. Explain where consumers find per-release notes and standing install/verification guidance. Do not document unfinished dashboard behavior as already available.
No broader release-channel redesign, historical note backfill, glossary change, or ADR change. Rollback retains its existing meaning: restore an observation-store snapshot, then install the earlier Release.

Blocked by

None (can start immediately).

## Parent [Implement dashboard clarity and release notes](https://git.bongbetic.com/xavierk/Fenris/issues/61) ## What to build Turn change notes into a working Release surface: maintainers record user-facing changes, release automation extracts the selected version, and consumers receive those notes together with standing installation, verification, and rollback guidance. Re-running release automation resynchronizes notes without duplicating uploaded assets. Deliver the entire authoring-to-release-body path, its tests, a scripted dispatch verification, and the README release-notes pointer. ## Acceptance criteria - [ ] DC-6: Adopt Keep a Changelog 1.1 shape. Keep `## [Unreleased]` at the top even when empty. Version headings use bracketed bare semver and a strict ISO date. Permit Added, Changed, and Fixed categories only, with security fixes under Fixed; entries are single imperative, user-facing bullets without commit hashes or issue numbers. - [ ] DC-7: A checked-in, unit-tested extractor accepts a changelog path and requested version and returns that version's section verbatim. Never fall back to Unreleased. Missing or empty sections and malformed dates emit `::error::` and exit nonzero. - [ ] The release workflow fails closed on a pushed tag that differs from `v` plus the project version. Skip only this tag guard on manual dispatch; section and date validation still apply. Validation failures prevent publication rather than producing a release without notes. - [ ] DC-8: Assemble the release body from the extracted version section verbatim plus a separate standing footer containing channel install one-liners, checksum verification, and a rollback pointer consistent with the existing packaging contract. Only the selected changelog section varies per version. - [ ] On rerun against an existing release, PATCH the body. Preserve current idempotent-skip behavior for uploaded assets and packages. Keep unrelated packaging, signing, and collector behavior unchanged. - [ ] Use the new pure-function extractor seam to test successful exact slices and fail-closed cases. Exercise its command boundary for diagnostics and exit status. Use existing release dry-run prior art for wiring checks; verify body assembly and create-versus-PATCH decisions with observable outputs or captured requests, not source-text checks alone. Automated tests require no production credentials or registry writes. - [ ] Record one scripted manual-dispatch verification of body assembly as DC-8 probe evidence, separate from automated unit evidence. Use an authorized test target/ref and document the resulting release body; do not count a dry run as the live probe or silently claim a blocked probe passed. - [ ] Document and support release discipline: entries land with each fixing change; one release commit bumps project version, renames Unreleased to the version heading, restores an empty Unreleased section, and is the commit tagged. No historical release backfill; initialize with empty Unreleased and record this mechanism and subsequent changes there. - [ ] Incorporate any user-facing entries supplied with sibling slices before the changelog convention landed. Do not delay a completed sibling slice solely for this infrastructure, and do not omit those entries from the first applicable Release. - [ ] Add the locked README release-notes pointer, coordinating the shared “Reading the dashboard” section with its other owners. Explain where consumers find per-release notes and standing install/verification guidance. Do not document unfinished dashboard behavior as already available. - [ ] No broader release-channel redesign, historical note backfill, glossary change, or ADR change. Rollback retains its existing meaning: restore an observation-store snapshot, then install the earlier Release. ## Blocked by None (can start immediately).

xavierk added the ready-for-agent label 2026-09-10 07:28:01 +00:00

xavierk referenced this issue

2026-09-10 14:13:56 +00:00

Distinguish monitoring continuity, Deliberate disable, and quitting #63

xavierk self-assigned this 2026-09-10 14:24:09 +00:00

xavierk commented

2026-09-10 15:41:14 +00:00

Implemented and released in f077fa6, cfdef63, 608ad7f, and release commit f406285 (v0.3.4).

DC-8 live manual-dispatch probe

Authorized target/ref: main at f406285a0fd09b5bc579325fa484cb8eaedeb4dd.
Dispatch command: tea api -X POST repos/xavierk/Fenris/actions/workflows/release.yml/dispatches -F ref=main.
Manual run #221 completed successfully. It created v0.3.4 with the extracted 0.3.4 section, standing install/verification/rollback footer, and exactly the deb, rpm, and clearsigned checksum assets.
The created release body is the dated 0.3.4 Added section (Fenris identity/authentication, continuity/Deliberate disable/quitting, and release notes) followed by the standing package-channel install one-liners, gpg --output SHA256SUMS --decrypt SHA256SUMS.asc plus sha256sum -c SHA256SUMS verification, and rollback guidance.
The release-created v0.3.4 tag triggered #222, which passed the pushed-tag guard and completed successfully. A final manual rerun #223 also completed successfully, exercising the existing-release PATCH path and preserving the same three assets.

Automated evidence: PYTHONPATH=.:src .venv/bin/pytest tests/ -q -> 405 passed, 34 skipped. The extractor unit/command tests cover exact slices and fail-closed diagnostics; request tests capture POST versus PATCH decisions.

This completes DC-6 through DC-8, release discipline, sibling entries, README pointer, and the scripted live probe.

Implemented and released in `f077fa6`, `cfdef63`, `608ad7f`, and release commit `f406285` (`v0.3.4`). ## DC-8 live manual-dispatch probe - Authorized target/ref: `main` at `f406285a0fd09b5bc579325fa484cb8eaedeb4dd`. - Dispatch command: `tea api -X POST repos/xavierk/Fenris/actions/workflows/release.yml/dispatches -F ref=main`. - Manual run [#221](https://git.bongbetic.com/xavierk/Fenris/actions/runs/221) completed successfully. It created [v0.3.4](https://git.bongbetic.com/xavierk/Fenris/releases/tag/v0.3.4) with the extracted `0.3.4` section, standing install/verification/rollback footer, and exactly the deb, rpm, and clearsigned checksum assets. - The created release body is the dated `0.3.4` Added section (Fenris identity/authentication, continuity/Deliberate disable/quitting, and release notes) followed by the standing package-channel install one-liners, `gpg --output SHA256SUMS --decrypt SHA256SUMS.asc` plus `sha256sum -c SHA256SUMS` verification, and rollback guidance. - The release-created `v0.3.4` tag triggered [#222](https://git.bongbetic.com/xavierk/Fenris/actions/runs/222), which passed the pushed-tag guard and completed successfully. A final manual rerun [#223](https://git.bongbetic.com/xavierk/Fenris/actions/runs/223) also completed successfully, exercising the existing-release PATCH path and preserving the same three assets. Automated evidence: `PYTHONPATH=.:src .venv/bin/pytest tests/ -q` -> 405 passed, 34 skipped. The extractor unit/command tests cover exact slices and fail-closed diagnostics; request tests capture POST versus PATCH decisions. This completes DC-6 through DC-8, release discipline, sibling entries, README pointer, and the scripted live probe.

xavierk closed this issue

2026-09-10 15:41:15 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: xavierk/Fenris#64