From 2e0f6d219bb23412b71cc150290cbc7794e6c25d Mon Sep 17 00:00:00 2001 From: Konstantin Tarkus Date: Wed, 2 Sep 2026 22:47:45 +0200 Subject: [PATCH 1/2] docs: correct what is editable on an immutable release "Managing releases in a repository" claimed that only the title and release notes can be edited after an immutable release is published. Measured against a repository with immutable releases enabled, a published release also accepts changes to its pre-release and latest flags and stays immutable; what is rejected is uploading or deleting assets and moving the tag. The allowlist also contradicted the concepts page, which lists exactly those two protections. Replace it with a denylist, and document on the concepts page that a release can be published as a pre-release, verified over the public download path a draft does not offer, and then promoted. --- .../concepts/supply-chain-security/immutable-releases.md | 6 ++++++ .../managing-releases-in-a-repository.md | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/content/code-security/concepts/supply-chain-security/immutable-releases.md b/content/code-security/concepts/supply-chain-security/immutable-releases.md index eb2aabfe5b98..ca5344fa34e1 100644 --- a/content/code-security/concepts/supply-chain-security/immutable-releases.md +++ b/content/code-security/concepts/supply-chain-security/immutable-releases.md @@ -29,6 +29,10 @@ Additionally, creating an immutable release automatically generates a **release If a release is immutable, you will see {% octicon "lock" aria-hidden="true" %} **Immutable**" below the title on the release page. +## What you can still change + +Immutability protects the assets and Git tag of a release. After an immutable release is published, you can still edit its title and release notes, and change whether it is marked as a pre-release or as the latest release. + ## Best practices for publishing immutable releases We recommend you use the following workflow for publishing an immutable release. @@ -39,6 +43,8 @@ We recommend you use the following workflow for publishing an immutable release. This ensures that all assets are in place before the release becomes immutable, preventing the need to work around immutability restrictions. +Draft releases are not public, so their assets cannot be downloaded the way consumers download them. To check that path before you promote a release, publish it as a pre-release, verify the published assets, then edit the release to clear **This is a pre-release** and select **Set as latest release**. + ## Next steps To learn how to enable immutable releases for your repository or organization, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/prevent-release-changes). diff --git a/content/repositories/releasing-projects-on-github/managing-releases-in-a-repository.md b/content/repositories/releasing-projects-on-github/managing-releases-in-a-repository.md index f8261ad24ec2..799c102ed936 100644 --- a/content/repositories/releasing-projects-on-github/managing-releases-in-a-repository.md +++ b/content/repositories/releasing-projects-on-github/managing-releases-in-a-repository.md @@ -81,7 +81,7 @@ If you @mention any {% data variables.product.github %} users in the notes, the {% ifversion immutable-releases %} > [!NOTE] -> If you have enabled immutable releases for your repository, you can only edit the title and release notes after a release is published. See [AUTOTITLE](/code-security/concepts/supply-chain-security/immutable-releases). +> If you have enabled immutable releases for your repository, you cannot add, replace, or delete assets after a release is published, and you cannot move or delete its tag while the release exists. You can still edit the title and release notes, and change whether the release is a pre-release or the latest release. See [AUTOTITLE](/code-security/concepts/supply-chain-security/immutable-releases). {% endif %} From daf07d576d89c44ebaf1349ab7a0fea8fc382b84 Mon Sep 17 00:00:00 2001 From: Konstantin Tarkus Date: Thu, 3 Sep 2026 14:45:23 +0200 Subject: [PATCH 2/2] docs: fold immutable-release edit scope into existing sections Review feedback: the new "What you can still change" heading and the prerelease-verify-promote paragraph were both extra structure on a short concepts page. Move the editable-fields sentence next to the protections it bounds, and point at the release-creation docs instead of restating the process. --- .../supply-chain-security/immutable-releases.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/content/code-security/concepts/supply-chain-security/immutable-releases.md b/content/code-security/concepts/supply-chain-security/immutable-releases.md index ca5344fa34e1..a360ba6f2873 100644 --- a/content/code-security/concepts/supply-chain-security/immutable-releases.md +++ b/content/code-security/concepts/supply-chain-security/immutable-releases.md @@ -22,6 +22,8 @@ When you enable immutable releases, the following protections are enforced: * **Git tags cannot be moved**: Once an immutable release is published, its associated Git tag is locked to a specific commit, cannot be changed, and cannot be deleted while the release exists. If you delete the immutable release, you can delete the tag, but you cannot reuse the same tag name. * **Release assets cannot be modified or deleted**: All files attached to the release (such as binaries and archives) are protected from modification or deletion. +Only the assets and tag are locked. You can still edit the title and release notes of a published immutable release, and change whether it is marked as a pre-release or as the latest release. + Additionally, creating an immutable release automatically generates a **release attestation**, which is a cryptographically verifiable record of a release containing the release tag, commit SHA, and release assets. Consumers can use this attestation to make sure the releases and artifacts they are using exactly match the published {% data variables.product.github %} releases. > [!NOTE] @@ -29,10 +31,6 @@ Additionally, creating an immutable release automatically generates a **release If a release is immutable, you will see {% octicon "lock" aria-hidden="true" %} **Immutable**" below the title on the release page. -## What you can still change - -Immutability protects the assets and Git tag of a release. After an immutable release is published, you can still edit its title and release notes, and change whether it is marked as a pre-release or as the latest release. - ## Best practices for publishing immutable releases We recommend you use the following workflow for publishing an immutable release. @@ -41,9 +39,7 @@ We recommend you use the following workflow for publishing an immutable release. 1. Attach all associated assets to the draft release. 1. Publish the draft release. -This ensures that all assets are in place before the release becomes immutable, preventing the need to work around immutability restrictions. - -Draft releases are not public, so their assets cannot be downloaded the way consumers download them. To check that path before you promote a release, publish it as a pre-release, verify the published assets, then edit the release to clear **This is a pre-release** and select **Set as latest release**. +This ensures that all assets are in place before the release becomes immutable, preventing the need to work around immutability restrictions. For more information, see [AUTOTITLE](/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release). ## Next steps