3 ms·
I actually like their conservative approach with version numbers. For what it's worth, in IPv4 time there were some experiments with a new IP variant, those g
by vog 9y ago
I actually like their conservative approach with version numbers.
For what it's worth, in IPv4 time there were some experiments with a new IP variant, those got the version 5. You won't find these anywhere in today's networks, but just to be sure, the next official version got number 6.
The opposite is what we see in some programs and libraries: First, they publish version 1.2.2. Then version 1.2.3. But ooops, 1.2.3 had an issue. Well, let's just release a new tarball and label it 1.2.3 as well. Hopefully nobody noticed this. How big are the chances that somebody downloaded the broken package during the past 2 hours? (I guess using another number for the fixed release, such as 1.2.4, would have been too expensive. Or so.)
- __s 9y agoLibraries at least should have mechanisms to release 1.2.4 & yank 1.2.3 from whichever package repos they're on. Package repos generally won't allow pushing an update to a version without version bump
- bandrami 9y agoThat's a horrible idea. What if I can't upgrade to 1.2.4?
- gvx 9y agoIt should always be possible to upgrade a patch level. How else would you get security updates?
- bandrami 9y agoI wait for it to be validated by the client and then apply the patch according to the established controls and protocols if the risk assessment team gives a green light.
- __s 9y agoFor crates.io it works out that if you yank a package no new packages can be published relying on the yanked version, but packages already relying on it can still download it
- lightbyte 9y agoHex.pm (for Erlang/Elixir packages) allows you to re-publish the same version multiple times as long as it's within a set window of time after the first upload.