Skip to content

Native GitHub Releases should include tagged notes and recognize the complete body #1111

Closed

Description

@rmcdaniel

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.

Activity

  1. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    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 3.5.0
    body sha256 before 50abf39f887a5d01e084181246447159079ba8f09d0a0cbee4b9bc7c3d1f9d94 4e3615f13468899f28b924531e5e45bb064414d0dc21789c37581e5c8ba9878b
    body sha256 after (read back) d877daec08417c22fb7033d09087c5bca2c1aa0d657ea5b87c171f606227f4dc 4ebfca22d5ea5b53b55fcd52662d8e4e6bc057abecdf2e8eca932262ceb3c10c
    after == prepared bytes yes yes
    after starts with the exact before bytes yes yes
    tag → commit, before and after commit:9a03565e8752102d04eac690a84008711e759fba (unchanged) commit:1b8e9ee4bc6402261cb465cb6996056bacedd97c (unchanged)
    assets, before and after none (unchanged) none (unchanged)
    draft / prerelease, before and after false / false (unchanged) false / false (unchanged)
    Latest release, before and after 3.8.0 (unchanged) 3.8.0 (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.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.

  2. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Writer repairs (reviewed native-github-release.yml at main, repair_legacy_notes=true):

    Release Run Result Stored body sha256 after Latest after
    3.8.0 43349860325 success: "Release 3.8.0 now carries its tagged notes; Latest is still 3.8.0." 7675332a46141de65b561570f6d3e741d90802ecd329de0c501e287c56646cbb 3.8.0
    3.6.0 43351547099 success: "Release 3.6.0 now carries its tagged notes; Latest is still 3.8.0." 38ecfb695746e265db263f72b232910ee719aa970f36b9b95eda43c1ef0b7831 3.8.0
    3.7.0 43350075441 refused, no write: "cannot read docs/releases/3.7.0.md at d041f5b…" unchanged 23102d6f927b46dcb7ecad6545aac3b63ad9257429a641869c4b73e8e215139b 3.8.0

    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. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    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.
    • Readbacks (condition 3):
    Before After
    Stored body sha256 23102d6f927b46dcb7ecad6545aac3b63ad9257429a641869c4b73e8e215139b b675e777b86cb8ad33cdc54c7b2f9185fcddd27ce4214caf90bd68b4f50f073e
    Tag → commit commit:d041f5ba9074c0a6a0bcc6b1cc821c8701772443 unchanged
    Assets none none
    Draft / prerelease false / false unchanged
    releases/latest 3.8.0 3.8.0

    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.

  4. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions