chore(release): v0.11.0 - #430
Merged
Merged
Conversation
Stamps the Unreleased section as v0.11.0, keeps an empty Unreleased above it, and updates VERSION and the README version lines. Adds a release intro in operator terms and a Known limits section covering the three things an operator should know that no Fixed entry says on its own: records written by earlier versions on the two corrected paths are not repaired, rollback_results is serialized but not signed in v1, and both engine corrections were verified offline only. Corrects VERSIONING_PLAN.md in two places. The release-process section said releases are manual and source-only with automation planned for v1.0; every release since v0.2.0 has been tag-triggered GoReleaser publishing signed rpm, deb, tarballs, an SBOM and a cosign-signed checksums file. The section now describes that, including that the tag push is publication and that the release page body must be set from the CHANGELOG afterwards because changelog generation is disabled. Adds the pre-1.0 exception the founder approved on 2026-09-20 for an api/ change that moves no signature but changes what an existing value means to a consumer: MINOR during 0.x, with the change stated in consumer terms and the consumer's written confirmation. Stated as a granted exception with its first use, not as a reading of the existing rule. 09-reference's stamp read "v0.10.0 plus Unreleased changes"; those changes are this release, so it now reads v0.11.0. The other guide chapters keep their v0.9.0 stamps: they were not re-verified for v0.10.0 and are not re-verified here.
cli-coverage-command-finalization AC-08 expected the CHANGELOG entry to sit under Unreleased and VERSION to be unchanged. Those were guards for the PR that landed the finalization, written into an approved criterion as permanent expectations. No release could satisfy them: releasing IS stamping Unreleased and changing VERSION. The v0.11.0 release PR failed its unit job on exactly this. The criterion now expects the entry at or after v0.11.0, the release that shipped it, and drops the VERSION guard. The test anchors the entry above the v0.10.0 heading, whichever section holds it, and no longer reads VERSION. Removing the entry fails the test. AC-08 carries approval_gate with approval_date 2026-09-08. That date is left as it was; the amended wording needs the founder's acceptance and is called out in the release PR.
…cope the old-evidence note Three corrections from review of the v0.11.0 release documents. The pre-1.0 exception in VERSIONING_PLAN.md read as a general license to change api/ value semantics whenever OpenWatch agreed. What was approved is narrower: a corrective change only, one that stops a value stating something false, approved per change, with the release documenting the compatibility assessment, the operator-visible effect and any migration. OpenWatch's written clearance is required and is evidence for OpenWatch alone; it says nothing about other consumers of api/. The text now says all of that. The release procedure said pull-request CI runs the release snapshot. It does not: the snapshot and govulncheck jobs run only on schedule or workflow_dispatch and show as skipped on a PR. The procedure now requires a candidate-specific dispatch, green on every job including those two, with the run id and head SHA recorded, before tagging. It also notes that nothing checks the tag against VERSION. The Known limits entry said persistence failures in earlier versions left unverifiable stored records. The old mutation rewrote the decision inside a RETURNED envelope after a committed, rolled-back or staged result was demoted because its persistence failed; Kensa did not store those, since storing them is what had failed, and a persistence failure that did not demote left the signature intact. Only the stranded-step case produced unverifiable STORED records. The entry now names the two cases separately and keeps the no-repair statement.
The criterion was accepted 2026-09-08 with changelog expectations that were PR-time guards written as permanent ones, and amended during the v0.11.0 release when no release could satisfy them. The amended wording carried the original approval date, so the record read as though the contract had been settled once. approval_date now carries the amendment acceptance, 2026-09-22, with a comment stating the original date, what changed and why. This follows the convention set by system-checkout-credential-non-persistence AC-01, which keeps both dates for the same reason.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release v0.11.0 on
mainatec21e6b: fourteen commits since v0.10.0. Three commits on this branch: the release stamp, a spec fix the stamp exposed, and three document corrections from review (the exception narrowed to corrective changes with per-change approval; the dispatch run named as the packaging gate; the old-evidence note scoped to stored stranded-step records versus returned demoted envelopes).Stamps
## Unreleasedas## v0.11.0 (2026-09-20)with an empty## Unreleasedkept above it, updatesVERSIONand the README version lines, and adds a release intro plus a### Known limitssection covering what no Fixed entry says on its own: earlier records on the two corrected evidence paths are not repaired,rollback_resultsis serialized but not signed in v1, and both engine corrections were verified offline only.Corrects
VERSIONING_PLAN.mdtwice. The release-process section described a manual, source-only process with automation planned for v1.0; every release since v0.2.0 has been tag-triggered GoReleaser publishing signed rpm, deb, tarballs, an SBOM and a cosign-signed checksums file, and the section now says so, including that the tag push is publication and that the release page body must be set from the CHANGELOG afterwards. It also records the founder-approved pre-1.0 exception under which anapi/change that moves no signature but changes what a value means to a consumer ships as MINOR, with its conditions and its first use.Spec amendment needing acceptance.
cli-coverage-command-finalizationAC-08, approved 2026-09-08, expected the coverage entry to sit under## UnreleasedandVERSIONto be unchanged. Those were guards for the PR that landed the finalization, written as permanent expectations, and no release could satisfy them: releasing is stamping Unreleased and changing VERSION. The first CI run on this branch failed its unit job on exactly that. The criterion now expects the entry at or after v0.11.0 and drops the VERSION guard; the test anchors the entry above the v0.10.0 heading and no longer reads VERSION.approval_dateis left at 2026-09-08 rather than forged; the amended wording needs founder acceptance.Why MINOR: two new subcommands and a CLI behavior change whose deprecation warning shipped in v0.1 rule out PATCH; the open v1.0 ship gates rule out MAJOR; the
api/semantic change in #429 ships under the exception above, with OpenWatch's written confirmation (OW-KN-048) that no consumer change is needed.Candidate verification performed locally on this head:
goreleaser release --snapshot --clean --skip=publish,signbuilds all 14 artifacts; the checksums file lists 11 and every one verifies.kensa,kensa-keygen,kensa-validate,kensa-systemd-helper, the sudoers drop-in, and a CHANGELOG carrying the v0.11.0 stamp. The noarch rules package carries 779 rules, matching the corpus.govulncheck ./...: 0 reachable vulnerabilities, the criterion the CI job gates on.docs-check,docs-style,docs-style-sync,comment-lintpass.CI on the head
7f0dee5: the pull-request run is green on every job it runs. Aworkflow_dispatchrun on the same head (run 35599621945) additionally ran the two clock-scheduled jobs: Release snapshot built all packages, archives and the checksums file, and Vulnerability Scan (govulncheck) passed. An earlier dispatch (35559210286) coveredfa2194dthe same way.Not done: the operator guide chapters other than 09-reference keep their v0.9.0 stamps. They were not re-verified command-by-command for v0.10.0 and are not re-verified here; chapter 05's status table was rewritten in #429 under review and describes v0.11.0 behavior under that older stamp. Live-host validation is excluded.
Tagging and publication await founder release acceptance.