Immutable releases are now generally available on GitHub

+1

Nobody thought about mutable releases being utterly bad _before_? Baffles me...

As bad as hardware vendors selling products with different chips inside as the same model (hello Cisco -- at least in former times; hello HP, formerly selling at least three different, _incompatible_ laptop power supplies with the same label).

Mutability: surprise, surprise, I'm not what you expected! -- maybe one of IT's worst ideas.

Once in a while someone makes a mistake and it is helpful to just fix it.

I've done it myself, create a release, upload it, download to a different machine and discover it doesn't work there, so fix and retest. Only after all those steps do I hit send on the release announcement. This is a useful workflow (particularly the first time you release when you don't even know what you are doing).

So long as nobody abuses that mutable releases are a great thing. However a tiny minority of people are not trustworthy and so we are forced to take away a great things because of that minority.

That is what ‘-1’ and the like are for.

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.

> Nobody thought about mutable releases being utterly bad _before_? Baffles me...

Some of us been requesting it as a feature since 2016, just because it wasn't implemented until now doesn't mean even people inside GitHub hasn't thought about it.

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.

It's funny they call it "adding a new layer of supply chain security", when I reported it in August 2015 I got this answer:

> Thanks for the submission. We have reviewed your report and determined that it does not present a security risk. Tags and releases are not directly associated. The author lookup for a given release is done when that release is created and not upon subsequent updates. I can see how that could lead to some confusing behavior. I passed your observations on to our developers to see if we would want to change that behavior in the future. But, given that it does not present a security risk, it is not eligible for reward under the Bug Bounty program.

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

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

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.