Go vgo: Semantic Versioning and Human Error

Re:Go vgo: Semantic Versioning and Human Error by tschellenbach on Monday May 21, 2018 @05:08PM (#17121850)

1. You should always fix your versions so things don't automatically upgrade 2. A good test suite will catch when things break so you don't find out in production. 3. Combining the above 2 it becomes easy to occasionally see which packages changed and upgrade to more recent versions. 4. After trying out a ton of dependency management tools (python, ruby, node, go, java) I think Yarn is the nicest solution i've worked with so far.

[ Parent | on HN ]

Re:Go vgo: Semantic Versioning and Human Error by TheDong on Monday May 21, 2018 @05:50PM (#17122142)

> don't automatically upgrade

You've missed the point; code neither automatically upgrades with MVS or with a lockfile. In both cases, it's a conscious decision to do so.

Helm likely had to update its dependencies (e.g. k8s dependency for k8s version compatibility) to solve a business problem, which makes it difficult to trivially downgrade that dependency (and thus break the business)

> A good test suite will catch when things break so you don't find out in production

helm has a good test suite; it wasn't good enough. A test suite is rarely, if ever, "good enough" to catch all bugs. That being the case, we must design in such a way that when a bug does occur, it can be easily resolved.

vgo reduces how many knobs we can twiddle to resolve a bug.

> After trying out a ton of dependency management tools (python, ruby, node, go, java)

None of those are dependency management tools. python has easy_install and two versions of pip. ruby has gem, bundler, and the mess that predated that. node has npm and yarn. go has dep, glide, gb, go get, and dozens of others. Java has maven, gradle, and others.

> I think Yarn is the nicest solution i've worked with so far

Totally irrelevant information without any additional data on that conclusion.

[ Parent | on HN ]