3 ms·
Semver is busted because it makes builds non-deterministic. Building the same code tomorrow may fail if a third party dependency publishes a change violating se
by dustingetz 12y ago
Semver is busted because it makes builds non-deterministic. Building the same code tomorrow may fail if a third party dependency publishes a change violating semver.
For example: https://github.com/bower/bower/issues/1404#issuecomment-48764816 https://github.com/bower/bower/issues/1404#issuecomment-4876...
I unfortunately can only complain, I have no solution to offer.
- bhaak 12y agoHuh? Which ecosystem advocates automatic updates and doesn't allow locking the version numbers of the dependencies until a developer manually updates them?
- wycats 12y agoNode?
- papaf 12y agoI think that Go does not lock the version numbers by default. However, you have to sync manually - its not like Maven that attempts to download the internet on every build.
- shtylman 12y agoSystems where people seem to live under the assumption that if they don't get the latest patch updates or security updates their code will somehow be inferior and they will instantly be hacked. They think that semver will magically solve the problems of having to keep your application dependencies up to date if you want the latest changes/features/fixes.
- dustingetz 12y agoThis particular example is javascript/Bower. A fresh clone and build of any javascript project using Bower has a non-deterministic build if it uses Bower's semver capabilites.
- bhaak 12y agoYes, I read up on it. That's quite insane that there is no automatic way of having the exact versions required when installing something with bower. Of course there will be lots of pain, it just takes one package to slightly violate SemVer and you'll have to hunt down the culprit. What surprises me is that in the article they seem to think that switching to another versioning scheme will help with this problem. Especially as better tools would mitigate most of this problem.