[danudey]

Depending on the project, doing a re-release with an appended or updated version number might be a huge hassle. For a small, single-binary program run by an agile team it's pretty trivial to recall a release and publish a replacement, but for larger open-source projects with long, complex, release processes, paying customers, external docs, etc., spending an entire new day doing an entire new release to fix one typo in one word in one file in one artifact is less practical than just re-uploading the file and updating your SHA256SUMS.

[cortesoft]

In that case, it seems like immutable releases aren't what that project wants. You don't HAVE to enable immutable releases.

The ability to change a release is fundamentally incompatible with immutable releases, by definition. You can have one or the other, not both.

[bluGill]

immutable releases are not what anyone wants. A few bad actors forced them on us.

[duskdozer]

idk, i've come across people who are really adamant about the idea of immutability for its own sake, even as far as never amending or rebasing

[bluGill]

i was likely too strong in saying nobody. Though they want immutabilty for theoretical purity reasons not for security which I'm sure is why github is doing this. Still it isn't bad toacknowledge them even if most don't care about their conterns.