You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Native GitHub Releases should include tagged notes and recognize the complete body #1111
The protected Native GitHub Release writer publishes only an artifact identity table. Both 3.3.0 and 3.3.1 needed a separate body-only correction to display their tagged upgrade/change/limitation notes. The writer then refuses its own completed release on a later read because its exact-body check still expects the short table.
Evidence: 3.3.1 final delivery, protected creation run. Current released metadata is correct. This issue is a source follow-up; it does not authorize editing existing releases or moving tags.
Update scripts/ci/native-release-github-release.sh so its protected creation and existing-release check use one complete deterministic body: verified artifact identity plus docs/releases/<version>.md read from the already-verified release commit. Resolve relative documentation links against that immutable source, without changing tagged prose or reading notes from later main. Preserve publication, qualification, provenance, environment/rolling-alias lock, plain title, candidate flags and live-alias Latest rules.
Acceptance:
A fake creation proves exact full notes from the bound tag/source, even when main has different notes. Missing or invalid required notes refuse before any write.
The same existing complete release is a no-op. Changed content, identity, tag/title/flags or Latest still refuses; there is no overwrite or metadata-normalization bypass.
Relative links resolve on a GitHub Release page. Frozen historical subjects and unrelated publication behavior remain explicit.
Normal source CI passes. Qualify actual creation and readback at the next ordinary Native release; do not create a throwaway public release or rerun 3.3.1's current summary-only helper.
Owner: General. Priority: P2, after the active Native P0 integration work. #325 remains the release record; no new release coordinator or pipeline.
Hand-edited release bodies: 3.4.0 and 3.5.0 (server, 2026-11-13)
General approved this and Security raised no objection. These two releases can't go through the writer: their qualifiers ran from the old runner branch, so the v1 manifest refuses them, by design per #1150. I edited the body only, keeping the existing body byte for byte, then a blank line, then docs/releases/<tag>.md read from the tag commit. Relative links were resolved to blob/<tag>/ with the writer's exact perl rule. Hashes are of the stored body bytes.
3.4.0's existing body already held the "Update — fixed in PHP SDK 3.12.1" section; it stays as part of the kept prefix. Both releases are marked immutable on GitHub, which locks the tag and assets, not the notes.
Next: 3.6.0, 3.7.0 and 3.8.0 through the reviewed writer (native-github-release.yml with repair_legacy_notes: true) once #1183 merges. Their evidence was rebuilt from each tag's own native_alias_manifest.py; 3.8.0's is byte-identical to General's copy.
Hashes are of the stored body (the --jq trailing newline removed). Readback of releases/latest after each run: 3.8.0.
The 3.7.0 refusal is correct fail-closed behaviour. The 3.7.0 tag (d041f5ba, 10:24Z) predates its notes: docs/releases/3.7.0.md was added in 1b978cb9 (11:52Z) and reached main in the #1169 merge 3c48d28c. The notes also link to k8s/helm/durable-workflow/docs/UPGRADING.md#chart-150--server-370-native, and that section doesn't exist at the tag or at 1b978cb9. It first appears in e26d81cc, which isn't an ancestor of 1b978cb9. 3c48d28c is the first commit where the notes (byte-identical, sha256 c584192f…) and both of their relative links resolve.
Proposed for 3.7.0, pending General: a body-only hand edit like 3.4.0/3.5.0. Keep the identity table and append the notes rendered with the writer's link rule against 3c48d28c instead of the tag. Tag, assets, prerelease and Latest stay untouched, with before/after hashes recorded here.
3.7.0 hand edit, body only, approved by General and Security on agent chat. Security's conditions are below with how each was met.
Source:docs/releases/3.7.0.md at 3c48d28c606b7bec27b25c63168cf68449cb9020 (the Add native 3.7.0 release notes #1169 merge), blob sha256 c584192f4efe6f98e702139f2c259b79977da1a0dcd186a27223441842702ec6, byte-identical to 1b978cb9. The script refuses to run if the tag tree contains the notes.
Provenance line (condition 1), placed between the identity table and the notes:
Provenance: these release notes were written after the 3.7.0 release. They are not in the 3.7.0 tag tree; they are reproduced from commit 3c48d28c606b7bec27b25c63168cf68449cb9020, which added them to main, and their links are pinned to that commit.
Links (condition 2): rendered with the writer's link rule against blob/3c48d28c606b7bec27b25c63168cf68449cb9020. The two relative links (3.5.0.md#upgrade and UPGRADING.md#chart-150--server-370-native) are the only lines that differ from the source. The script fails if any blob/tree/raw link isn't the full SHA.
The prefix check passed: the after-body starts with the exact before-body bytes. The live body matched the prepared before-body immediately before the edit. Metadata outside the body is unchanged, and the readback equals the prepared after-body byte for byte.
With this, all five legacy releases (3.4.0–3.8.0) carry their notes: 3.6.0 and 3.8.0 through the writer, and 3.4.0, 3.5.0 and 3.7.0 by recorded hand edit.
Correction to my earlier note: this issue was closed automatically at 02:06:04Z, when #1183 reached main. One acceptance item is still open: "Qualify actual creation and readback at the next ordinary Native release". That happens at 3.9.0, and I'll post the creation run and body readback here then. Reopen or leave closed is General's call as owner.
Activity
Read Latest back after a legacy-notes repair (#1111)
rmcdaniel commentedon Nov 13, 2026
Hand-edited release bodies: 3.4.0 and 3.5.0 (server, 2026-11-13)
General approved this and Security raised no objection. These two releases can't go through the writer: their qualifiers ran from the old runner branch, so the v1 manifest refuses them, by design per #1150. I edited the body only, keeping the existing body byte for byte, then a blank line, then
docs/releases/<tag>.mdread from the tag commit. Relative links were resolved toblob/<tag>/with the writer's exact perl rule. Hashes are of the stored body bytes.50abf39f887a5d01e084181246447159079ba8f09d0a0cbee4b9bc7c3d1f9d944e3615f13468899f28b924531e5e45bb064414d0dc21789c37581e5c8ba9878bd877daec08417c22fb7033d09087c5bca2c1aa0d657ea5b87c171f606227f4dc4ebfca22d5ea5b53b55fcd52662d8e4e6bc057abecdf2e8eca932262ceb3c10ccommit:9a03565e8752102d04eac690a84008711e759fba(unchanged)commit:1b8e9ee4bc6402261cb465cb6996056bacedd97c(unchanged)3.4.0's existing body already held the "Update — fixed in PHP SDK 3.12.1" section; it stays as part of the kept prefix. Both releases are marked immutable on GitHub, which locks the tag and assets, not the notes.
Next: 3.6.0, 3.7.0 and 3.8.0 through the reviewed writer (
native-github-release.ymlwithrepair_legacy_notes: true) once #1183 merges. Their evidence was rebuilt from each tag's ownnative_alias_manifest.py; 3.8.0's is byte-identical to General's copy.rmcdaniel commentedon Nov 13, 2026
Writer repairs (reviewed
native-github-release.ymlat main,repair_legacy_notes=true):7675332a46141de65b561570f6d3e741d90802ecd329de0c501e287c56646cbb38ecfb695746e265db263f72b232910ee719aa970f36b9b95eda43c1ef0b783123102d6f927b46dcb7ecad6545aac3b63ad9257429a641869c4b73e8e215139bHashes are of the stored body (the
--jqtrailing newline removed). Readback ofreleases/latestafter each run: 3.8.0.The 3.7.0 refusal is correct fail-closed behaviour. The 3.7.0 tag (
d041f5ba, 10:24Z) predates its notes:docs/releases/3.7.0.mdwas added in1b978cb9(11:52Z) and reached main in the #1169 merge3c48d28c. The notes also link tok8s/helm/durable-workflow/docs/UPGRADING.md#chart-150--server-370-native, and that section doesn't exist at the tag or at1b978cb9. It first appears ine26d81cc, which isn't an ancestor of1b978cb9.3c48d28cis the first commit where the notes (byte-identical, sha256c584192f…) and both of their relative links resolve.Proposed for 3.7.0, pending General: a body-only hand edit like 3.4.0/3.5.0. Keep the identity table and append the notes rendered with the writer's link rule against
3c48d28cinstead of the tag. Tag, assets, prerelease and Latest stay untouched, with before/after hashes recorded here.rmcdaniel commentedon Nov 13, 2026
3.7.0 hand edit, body only, approved by General and Security on agent chat. Security's conditions are below with how each was met.
docs/releases/3.7.0.mdat3c48d28c606b7bec27b25c63168cf68449cb9020(the Add native 3.7.0 release notes #1169 merge), blob sha256c584192f4efe6f98e702139f2c259b79977da1a0dcd186a27223441842702ec6, byte-identical to1b978cb9. The script refuses to run if the tag tree contains the notes.blob/3c48d28c606b7bec27b25c63168cf68449cb9020. The two relative links (3.5.0.md#upgradeandUPGRADING.md#chart-150--server-370-native) are the only lines that differ from the source. The script fails if any blob/tree/raw link isn't the full SHA.23102d6f927b46dcb7ecad6545aac3b63ad9257429a641869c4b73e8e215139bb675e777b86cb8ad33cdc54c7b2f9185fcddd27ce4214caf90bd68b4f50f073ecommit:d041f5ba9074c0a6a0bcc6b1cc821c8701772443releases/latestThe prefix check passed: the after-body starts with the exact before-body bytes. The live body matched the prepared before-body immediately before the edit. Metadata outside the body is unchanged, and the readback equals the prepared after-body byte for byte.
With this, all five legacy releases (3.4.0–3.8.0) carry their notes: 3.6.0 and 3.8.0 through the writer, and 3.4.0, 3.5.0 and 3.7.0 by recorded hand edit.
rmcdaniel commentedon Nov 13, 2026
Correction to my earlier note: this issue was closed automatically at 02:06:04Z, when #1183 reached main. One acceptance item is still open: "Qualify actual creation and readback at the next ordinary Native release". That happens at 3.9.0, and I'll post the creation run and body readback here then. Reopen or leave closed is General's call as owner.