immutable releases

[travi]

new github feature in public preview that we should prepare to be compatible with. i don't know that this is something that directly relates to our process of creating the release since it is more of a setting of how releases are defined when created at the repo/org level, but we should confirm that there are no surprises with this.

https://github.blog/changelog/2025-08-26-releases-now-support-immutability-in-public-preview/

[babblebey]

Sure thing 👍🏾

[viceice]

is this plugin working with immutable releases?

[travi]

tl;dr: this plugin does not handle immutable releases today

immutable releases are an complicated concept in this context. to be clear, we value immutability of released assets. however, since we cannot ensure an atomic release process, there are failure scenarios where immutability can result in partial releases that cannot be retried and are therefore forced to essentially be skipped. in some scenarios that is ok. in others, that might not be the right choice.

for example, when releasing to npm, the npm registry is mostly immutable. if we were to also use immutable releases on github, a failed publish to the npm registry would result in an immutable tag on github, but no release available through the npm registry. the normal recovery from that situation is to resolve the problem that prevented the release to the npm registry, delete the tag from github, and retry. if the tag is immutable, that tag couldnt be removed, semantic-release would find no changes since the most recent tag, and would not attempt to release anything to npm until the next commit is made that would trigger a new release (and the previous unreleased features would not be included in the release notes).

however, in scenarios where github acts as the registry, this scenario is different. the immutable release doesnt run into the conflict because the github release and the asset release are at least more related. that raises a new question though. is the scope of this plugin intended to include both the source control host details (essentially release notes through gh releases + comments on related issues and PRs) and the released assets? originally, i'd say it was not intended to include the latter. i think we still have decisions to make around whether that should be included in this scope or be handled by two plugins:

• github as source control host
• github as released assets registry

could you help us understand the use case you are trying to solve? more context could help us consider options

[travi]

also worth calling out that it has been a bit since i've investigated how the github side of this works, so if anything i've described isn't aligned with the reality of the process, i'm more than open to having my understanding improved

[travi]

here is a good example that reinforces why i think our recommendation needs to be to avoid immutable releases when publishing to a registry that isnt the github release. immutability is important, but is a responsibility of the registry, not the source repository when both are involved.