Repository navigation
Release and propagation guidance uses direct technical prose - #266
Open
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
Open
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
Conversation
9 tasks done
There was a problem hiding this comment.
🟢 Approved
No active review issues remain for the release-management and downstream-propagation documentation clarifications.
No open issues 🎉
What changed in this PR
This documentation-only PR clarifies release management and downstream propagation guidance with direct technical prose. It preserves the existing release contracts, commands, safeguards, and consumer policies.
Changes:
- Separates publication hazards, recovery rules, and version-baseline explanations into clearer statements.
- Clarifies moved-tag safeguards, consumer qualification, and delegation states.
- Uses en-US prose while preserving existing anchors, technical identifiers, and generated indexes.
| File | Description |
|---|---|
src/docs/Capabilities/release-management/spec.md |
Clarifies release entry paths, publication hazards, and durable intent. |
src/docs/Capabilities/release-management/index.md |
Simplifies the capability overview. |
src/docs/Capabilities/release-management/design.md |
Clarifies lifecycle rules, version baselines, and announcement delivery. |
src/docs/Capabilities/release-management/design-publishing-targets.md |
Separates completion, retry, withdrawal, and target constraints. |
src/docs/Capabilities/release-management/accept-moved-release-tags.md |
States trusted-remote and exact-version-tag safeguards directly. |
src/docs/Capabilities/downstream-release-propagation/spec.md |
Clarifies dependency risks, delegated upgrades, and backfill. |
src/docs/Capabilities/downstream-release-propagation/index.md |
Simplifies upgrade and no-upgrade outcome descriptions. |
src/docs/Capabilities/downstream-release-propagation/design.md |
Clarifies triggers, prompt context, qualification, and execution states. |
Review effort: Balanced
Marius Storhaug (MariusStorhaug)
marked this pull request as ready for review
November 4, 2026 14:43
This branch has not been deployed
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
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 and downstream propagation guidance uses direct en-US statements for publication hazards, recovery, consumer qualification, and delegation. Contributors, operators, and consumers can read each condition separately. No release behavior, setting, permission, command, or consumer policy changes, and readers do not need to change configuration or references.
Changed: Release and consumer handoff guidance is explicit
The release spec separates partial publication, mutable pull-request metadata, and advancing source. It retains all three consequences of recomputing from current state: different bytes under a reserved version, omitted accumulated changes, and advertising an incomplete release. The lifecycle design separates reservation and consumer-change baselines without changing their version example or publication lineage.
Publishing-target prose separates completion, retry, and withdrawal explanations. The moved-tag guide states the trusted-remote check and exact-version-tag safeguard directly. Propagation guidance describes outdated references without idioms and separates prompt context, qualification, paused execution, completion, and failure. Guide instructions remain imperative. These changes clarify the documented target-state contract; they do not prove that a producer implements or enforces it.
Technical details
Scope and immutable evidence
The fixed review baseline and scoped PR base are
1b0d4893c8fefabe604d04393068a8ff6f848082. The completed prose head is21c7794d00990954e059de2d7e82cbf48ebf2512. The scoped comparison isgit diff 1b0d4893c8fefabe604d04393068a8ff6f848082 21c7794d00990954e059de2d7e82cbf48ebf2512 -- src/docs/Capabilities/release-management src/docs/Capabilities/downstream-release-propagation.All eight assigned pages were read in full and changed. There are no unchanged owned pages. Only these eight paths differ from the baseline. Front matter, shared indexes, scripts/tests, workflow/configuration, dependencies, and the paths owned by #240 are unchanged. Both generated INDEX blocks are byte-identical; only handwritten index prose changes. No restructure, new tooling, or enforcement is added.
Concrete before/after evidence
originis the intended trusted producer and that no exact-version-tag integrity incident is being normalized.”originis the intended trusted producer. Do not use this procedure to accept a moved exact version tag.” All backup, pruning, force-fetch, trust-boundary, and verification commands remain exact.Preservation and semantic review
A one-off read-only comparison against the fixed baseline confirms unchanged front matter, heading/anchor lines, links, inline-code sequence, all 40 fenced blocks, all 182 BCP 14 keyword occurrences in their original sequence, and both generated INDEX blocks. The complete release-spec requirements and scenarios, from
## Requirementsthrough the end of the page, are byte-identical. All eight test-first prose acceptance examples pass after reporting eight expected failures before editing. The five selected hazard/consequence sentences contain 8-16 whitespace-delimited words; that check is not a full STE-conformance claim.Manual comparison confirms that these contracts retain their meaning: durable intent and phase-aware recovery; permanent reservations and immutable source/artifact identity; approved source and provenance; labels, defaults, version/channel/target rules; publication lineage and source-bound notes; adoption and template evidence; bounded consumer policies and narrower pinning standards; moved-tag safeguards; fixed propagation targets, no-upgrade disposition, correlated execution, untrusted evidence boundaries, permissions, and human review. A normative requirement remains a contract, not implementation or CI-enforcement evidence.
The existing
Failure behaviourheading stays unchanged to preserve its anchor. Exact API states such ascancelled, technical nouns/verbs, identifiers, native syntax, examples, guide imperatives, and generated output are accepted differences. No policy contradiction or cross-owned repair is introduced or left unresolved by this diff.Validation and plan progress
Local Markdown lint processed the exact eight assigned files and reported zero issues. The existing relative-link check passed for 130 documentation pages. The cross-repository check resolved all 7 links across 134 Markdown files. The existing pinned Pester 6.0.1 runner passed all 66 tests in 6 suites locally and again in final-head CI. No executable code or test changed. The final local build passed with existing Zensical 0.0.50; final-head CI also passed with the declared 0.0.59 requirement. No dependencies or tooling were added or changed.
git diff --checkpasses, and the clean local/remote branch heads both equal the immutable head above.21c7794d00990954e059de2d7e82cbf48ebf2512The Task's source review, all-page reading, test-first examples, first complete improvement, early draft PR, producer prose, consumer prose, and final verification are complete. The Task body records the full path dispositions, before/after evidence, validation links, accepted differences, and immutable delivery record. The work is delivered in three small, pushed commits. No remaining blocker is identified.
This PR remains open and draft, assigned to its author, by request. No ready transition or merge is requested. GitHub auto-merge is absent, Agent merge is disabled and has never run, and there are no
release:*labels.The scoped convergence sweep searched open MSXOrg/docs issues for
"release-management" in:title,bodyand"downstream release propagation" in:title,body. It found the closing Task and separate campaign Tasks #246, #247, #249, #253, and #255. Their separately owned deliverables are not closed by this eight-page diff. No additional issue converges.Standards and framework alignment
The standard set is fixed at the review baseline: Documentation Model, Natural Language, Technical Writing Guide, Markdown, Documentation, and the applicable specification/design/guide templates. The official STEMG overview and FAQ were read; relevant Issue 9 rules and dictionary entries were consulted from the verified local PDF/extract. The PDF MD5 is
9c720341c350ed77943b2c73d01c716f. Reference copies remain local and are not republished. These checks do not claim full STE conformance.src/docs/Capabilities/release-management/spec.mdsrc/docs/Capabilities/release-management/design.mdsrc/docs/Capabilities/release-management/design-publishing-targets.mdsrc/docs/Capabilities/release-management/accept-moved-release-tags.mdsrc/docs/Capabilities/release-management/index.mdsrc/docs/Capabilities/downstream-release-propagation/spec.mdsrc/docs/Capabilities/downstream-release-propagation/design.mdsrc/docs/Capabilities/downstream-release-propagation/index.mdThe effective repository route in
.github/workflows/Docs.ymlbuilds documentation and deploys Pages. The workflow set has no versioned release route. A Pages deployment alone does not invoke Release Management, so there is no release-decision block, publication-baseline claim, orrelease:*label.Related references