[skybrian]

Yes, you are right. And I believe vgo is supposed to guarantee reproducible builds just like other package systems.

However, when you upgrade a dependency, it's still possible that you're using a particular combination of library versions that have never been tested before.

Some incompatibilities can be prevented by looking at version constraints. But you're not left with no error detection if the package system fails to detect an incompatibility; in the end, what matters is that the code compiles and the tests pass.

[oceanswave]

This methodology places way too much emphasis on the breadth of the tests into a test centric view— say you had a dep that had an SSL vulnerability - most of the time you’re not going to be checking for this type of thing at the level of your app, and doing so - but you bet you need to ensure that you are using the version of the dep that has the vulnerability fixed

[skybrian]

I'm not sure they're entirely distinct. For example, if the SSL library exports a constant containing a version number, you could write a test asserting that it's not the bad version.

It's not as good as testing for the vulnerability, but then again no form of version number checking does that. (This is similar to the principle in web development that feature detection is better than version string checking. But sometimes version-checking is the best you can do.)

Checking version numbers in the package system allows for much faster backtracking, making it feasible to try many versions and select a combination that (hopefully) works. But verification can be done using testing.