From 6554b08291cde9f7a044d5233794f46610055562 Mon Sep 17 00:00:00 2001 From: Torsten Mahr Date: Sat, 19 Sep 2026 19:59:38 +0200 Subject: [PATCH 1/2] Widen R05 and R07 for repositories that release through a shared pipeline (1.13.0) R07: the changelog gate may live in a shared release pipeline the repository documents, not only in a workflow it owns. R05: a smoke test of the published artifact, done once and recorded, is enough; a clean environment and automation are no longer required, so R05 leaves the runner lists. Both widen a criterion, so this is a minor bump. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01Ez14nyXC16CaNvU6z7vN6W --- .github/badges/conformance.svg | 6 +++--- .github/conformance.yml | 4 ++-- CHANGELOG.md | 15 +++++++++++++++ docs/repository-quality-standard.md | 29 +++++++++++++++++++++++------ standard.yml | 8 ++++---- templates/conformance.yml | 2 +- 6 files changed, 48 insertions(+), 16 deletions(-) diff --git a/.github/badges/conformance.svg b/.github/badges/conformance.svg index 6f85935..2f968c4 100644 --- a/.github/badges/conformance.svg +++ b/.github/badges/conformance.svg @@ -1,10 +1,10 @@ - - trsdn standard: v1.12.0 - Healthy + + trsdn standard: v1.13.0 - Healthy trsdn standard - v1.12.0 - Healthy + v1.13.0 - Healthy diff --git a/.github/conformance.yml b/.github/conformance.yml index 5b1b424..a2d6837 100644 --- a/.github/conformance.yml +++ b/.github/conformance.yml @@ -6,8 +6,8 @@ # The badge in .github/badges/ is generated from this file. Change the evidence # first, then this record, then regenerate. Never the other way round. -standard_version: "1.12.0" -assessed_on: "2026-09-17" +standard_version: "1.13.0" +assessed_on: "2026-09-19" state: "Healthy" evidence: "docs/self-assessment.md" diff --git a/CHANGELOG.md b/CHANGELOG.md index af3424b..85fee29 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,21 @@ recorded here. Versions follow the compatibility policy in the [Repository Quality Standard](docs/repository-quality-standard.md). +## 1.13.0 - 2026-09-19 + +- Widened `R07`: the changelog gate may live in a shared release pipeline that + publishes the repository's releases, provided that pipeline refuses to publish + without the entry and the repository documents it. A repository does not have + to own a release workflow to keep release notes and changelog from drifting. +- Widened `R05`: a built artifact needs to have been smoke-tested once as a + consumer receives it (the published file, installed and launched), with the + result recorded. A clean environment and automation are no longer required, + and `R05` no longer needs a runner, so it leaves the runner lists in + [Automation Availability](docs/repository-quality-standard.md#automation-availability). +- Released as minor: both changes widen a criterion, so a recorded `Fail` may now + be a `Pass` and no recorded `Pass` can weaken, under + [Versioning And Compatibility](docs/repository-quality-standard.md#versioning-and-compatibility). + ## 1.12.0 - 2026-09-17 - Retired `W05` and `W06`, which required every published site to vendor diff --git a/docs/repository-quality-standard.md b/docs/repository-quality-standard.md index edaea6f..f4828a4 100644 --- a/docs/repository-quality-standard.md +++ b/docs/repository-quality-standard.md @@ -1,6 +1,6 @@ # Repository Quality Standard -- Version: 1.12.0 +- Version: 1.13.0 - Last reviewed: 2026-09-17 - Review cadence: every six months, even when nothing changes @@ -358,7 +358,7 @@ guarded by a label, an approval, or a maintainer's attention. ## Package And Release Repositories -`R03`, `R05`, and `R07` require a runner. Where none is available, +`R03` and `R07` require a runner. Where none is available, [Automation Availability](#automation-availability) states what is recorded instead. @@ -368,9 +368,9 @@ instead. | R02 | Versioning and compatibility policy are documented | README or release guide | | R03 | A tag produces installable artifacts through automation | Release workflow and uploaded release assets | | R04 | Tag, package version, and release title are consistent | Release workflow validation | -| R05 | Built artifacts are smoke-tested in a clean environment | CI or release workflow | +| R05 | A built artifact has been smoke-tested as a consumer receives it: the published file installed and launched, and its core function exercised. The result is recorded | A workflow that does it, or a dated record naming the version tested and what was exercised | | R06 | Release notes describe meaningful changes and upgrade concerns | GitHub release or changelog | -| R07 | Release notes are generated from the changelog entry for the version being released, and automation fails the release when that entry is missing, empty, or still held in an unreleased section | Release workflow gate plus a published release whose notes match its changelog entry | +| R07 | Release notes are generated from the changelog entry for the version being released, and automation fails the release when that entry is missing, empty, or still held in an unreleased section | Release workflow gate, in this repository or in a shared release pipeline this repository documents, plus a published release whose notes match its changelog entry | | R08 | A consumer can verify that a published artifact came from this repository, or the repository states why they cannot | Registry provenance, a build attestation, or a recorded statement | `R06` and `R07` divide the work. `R06` is about content: notes a reader can act @@ -395,9 +395,26 @@ exits non-zero when the result is empty, and passes that same text to the release command as the notes body, so the published notes and the maintained entry cannot disagree. +The gate does not have to live in this repository. A repository whose releases +are built and published by a shared pipeline it does not own, such as a +notarization broker or an organisation-wide release service, satisfies `R07` +when that pipeline refuses to publish without the changelog entry and the +repository documents that it does. The repository's part is to keep the entry; +the pipeline's part is to refuse without it. The evidence is the pipeline's +documented gate and a published release whose notes match the entry. + A reusable starting point is published as [`templates/release-notes/`](../templates/release-notes/). +`R05` asks for the fact, not the mechanism. Someone has to have taken the file a +consumer downloads, installed it, launched it and used its core function, and +written down that it worked and for which version. Doing that once is enough. A +clean environment is not required: the failure it guards against is a build that +only works on the machine that made it, and testing the *published* artifact +rather than the local build catches that. Automating the test is encouraged, +because it repeats on every release, but it is not required. A later release that +changes how the artifact is built, signed, or packaged is due for a new record. + `R08` covers the other half of what a consumer receives. `R03` establishes that a tag produces the artifact through automation and `R05` that the artifact works, but neither lets somebody who downloads it later establish where it came @@ -698,7 +715,7 @@ not restate the secret-handling requirements in `S05`, `S06`, `S07`, and `D02`. ## Automation Availability -Eight criteria name a workflow run as their evidence, and one required badge +Seven criteria name a workflow run as their evidence, and one required badge reports one. A repository with no runner cannot produce any of it, and none of those criteria say what an assessor records instead. This section says it once, because a rule restated in eight places drifts. @@ -724,7 +741,7 @@ ones: | Which criteria | Result when no runner is available | |---|---| | Those satisfied by a check the repository owns, which a runner only makes convenient. At this version `S02`, `S03`, and `L04` | `Fail` where the check does not exist; otherwise `Pass` where the documented `B05` command runs the check and the evidence the conformance record links to records a successful run of that command, and `Partial` where it does not | -| Those whose evidence can only be produced by a workflow run. At this version `S04`, `S09`, `R03`, `R05`, `R07`, and `P09` | `Not applicable` | +| Those whose evidence can only be produced by a workflow run. At this version `S04`, `S09`, `R03`, `R07`, and `P09` | `Not applicable` | **Membership is decided by the property, not by the list.** Each list names the criteria that match at the version on the cover, and is there so an assessor can diff --git a/standard.yml b/standard.yml index 9458958..c843e18 100644 --- a/standard.yml +++ b/standard.yml @@ -3,7 +3,7 @@ # Generated by scripts/standard.py from # docs/repository-quality-standard.md. Do not edit by hand. -version: "1.12.0" +version: "1.13.0" last_reviewed: "2026-09-17" prefixes: @@ -224,8 +224,8 @@ criteria: evidence: "Release workflow validation" - id: "R05" section: "Package And Release Repositories" - requirement: "Built artifacts are smoke-tested in a clean environment" - evidence: "CI or release workflow" + requirement: "A built artifact has been smoke-tested as a consumer receives it: the published file installed and launched, and its core function exercised. The result is recorded" + evidence: "A workflow that does it, or a dated record naming the version tested and what was exercised" - id: "R06" section: "Package And Release Repositories" requirement: "Release notes describe meaningful changes and upgrade concerns" @@ -233,7 +233,7 @@ criteria: - id: "R07" section: "Package And Release Repositories" requirement: "Release notes are generated from the changelog entry for the version being released, and automation fails the release when that entry is missing, empty, or still held in an unreleased section" - evidence: "Release workflow gate plus a published release whose notes match its changelog entry" + evidence: "Release workflow gate, in this repository or in a shared release pipeline this repository documents, plus a published release whose notes match its changelog entry" - id: "R08" section: "Package And Release Repositories" requirement: "A consumer can verify that a published artifact came from this repository, or the repository states why they cannot" diff --git a/templates/conformance.yml b/templates/conformance.yml index c8ebcea..97b8eee 100644 --- a/templates/conformance.yml +++ b/templates/conformance.yml @@ -20,7 +20,7 @@ # The badge is generated from this file. Change the evidence first, then this # record, then regenerate. Never the other way round. -standard_version: "1.12.0" +standard_version: "1.13.0" assessed_on: "YYYY-MM-DD" state: "Needs work" evidence: "docs/self-assessment.md" From 84ca1ce7d3815c48d60f454e6d074f5b004da498 Mon Sep 17 00:00:00 2001 From: Torsten Mahr Date: Sat, 19 Sep 2026 20:03:36 +0200 Subject: [PATCH 2/2] Widen R08 for shared release pipelines Where a shared pipeline the repository documents builds and publishes its releases, that pipeline's verifiable record is sufficient evidence of origin. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01Ez14nyXC16CaNvU6z7vN6W --- CHANGELOG.md | 5 ++++- docs/repository-quality-standard.md | 10 +++++++++- standard.yml | 4 ++-- 3 files changed, 15 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 85fee29..88c373a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -17,7 +17,10 @@ Versions follow the compatibility policy in the result recorded. A clean environment and automation are no longer required, and `R05` no longer needs a runner, so it leaves the runner lists in [Automation Availability](docs/repository-quality-standard.md#automation-availability). -- Released as minor: both changes widen a criterion, so a recorded `Fail` may now +- Widened `R08`: where a shared pipeline the repository documents builds and + publishes its releases, that pipeline's own verifiable record (for a macOS app, + the Developer ID signature and notarization) is sufficient evidence of origin. +- Released as minor: these changes widen a criterion, so a recorded `Fail` may now be a `Pass` and no recorded `Pass` can weaken, under [Versioning And Compatibility](docs/repository-quality-standard.md#versioning-and-compatibility). diff --git a/docs/repository-quality-standard.md b/docs/repository-quality-standard.md index f4828a4..d9fc26d 100644 --- a/docs/repository-quality-standard.md +++ b/docs/repository-quality-standard.md @@ -371,7 +371,7 @@ instead. | R05 | A built artifact has been smoke-tested as a consumer receives it: the published file installed and launched, and its core function exercised. The result is recorded | A workflow that does it, or a dated record naming the version tested and what was exercised | | R06 | Release notes describe meaningful changes and upgrade concerns | GitHub release or changelog | | R07 | Release notes are generated from the changelog entry for the version being released, and automation fails the release when that entry is missing, empty, or still held in an unreleased section | Release workflow gate, in this repository or in a shared release pipeline this repository documents, plus a published release whose notes match its changelog entry | -| R08 | A consumer can verify that a published artifact came from this repository, or the repository states why they cannot | Registry provenance, a build attestation, or a recorded statement | +| R08 | A consumer can verify that a published artifact came from this repository or from the shared release pipeline that publishes its releases, or the repository states why they cannot | Registry provenance, a build attestation, the shared pipeline's documented and verifiable record, or a recorded statement | `R06` and `R07` divide the work. `R06` is about content: notes a reader can act on. `R07` is about provenance: the notes a consumer actually receives are the @@ -430,6 +430,14 @@ absence it would replace, and it does not ask for a software bill of materials, which is ecosystem-specific tooling that few consumers of these repositories read. +Where a shared pipeline the repository documents builds and publishes its +releases, that pipeline's own verifiable record is sufficient evidence of origin. +A macOS app released through a notarization broker is the model case: the +Developer ID signature and Apple's notarization tie the artifact to the +publisher's identity and can be checked by anyone with `codesign` and `spctl`, +which is what the repository documents. The repository states what a consumer +can check and how, and what the record does not prove. + Where no such mechanism is available to this repository, a recorded statement of that fact is a `Pass`. Availability is the property, and it fails in two ways: an ecosystem that issues no provenance at all, and a repository with no runner, diff --git a/standard.yml b/standard.yml index c843e18..03b1000 100644 --- a/standard.yml +++ b/standard.yml @@ -236,8 +236,8 @@ criteria: evidence: "Release workflow gate, in this repository or in a shared release pipeline this repository documents, plus a published release whose notes match its changelog entry" - id: "R08" section: "Package And Release Repositories" - requirement: "A consumer can verify that a published artifact came from this repository, or the repository states why they cannot" - evidence: "Registry provenance, a build attestation, or a recorded statement" + requirement: "A consumer can verify that a published artifact came from this repository or from the shared release pipeline that publishes its releases, or the repository states why they cannot" + evidence: "Registry provenance, a build attestation, the shared pipeline's documented and verifiable record, or a recorded statement" - id: "I01" section: "Product Identity" requirement: "The built artifact embeds its product name and exact version"