←back to thread

151 points fastest963 | 2 comments | | HN request time: 0s | source
Show context
hoistbypetard ◴[] No.45772532[source]
My instant reaction was: "Wait?! They weren't immutable before?"

I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.

replies(6): >>45772557 #>>45772741 #>>45772761 #>>45773634 #>>45773953 #>>45774010 #
GuestFAUniverse ◴[] No.45772761[source]
+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.

replies(2): >>45773152 #>>45773832 #
bluGill ◴[] No.45773152[source]
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.

replies(1): >>45773672 #
cortesoft ◴[] No.45773672[source]
That is what ‘-1’ and the like are for.
replies(1): >>45773711 #
danudey ◴[] No.45773711[source]
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.
replies(1): >>45774567 #
cortesoft ◴[] No.45774567[source]
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.

replies(1): >>45777614 #
bluGill ◴[] No.45777614[source]
immutable releases are not what anyone wants. A few bad actors forced them on us.
replies(1): >>45780317 #
1. duskdozer ◴[] No.45780317[source]
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
replies(1): >>45781484 #
2. bluGill ◴[] No.45781484[source]
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.