The fact that services such as gopkg.in always redirect the go get tool to the latest available major version for a given version selector is, technically speaking, a show-stopper for engineering teams that endeavor to set up a development pipeline that guarantees repeatable builds. The typical CI pipeline will always pull both compile and test dependencies via a command such as go get -t -u ... prior to building the final output artifact. As a result, even if your code has not changed between builds, your service or application binary may be different because of changes in the dependencies that get pulled in.
However, what if I told you that there is actually a way to retain the benefits of lazy package resolution and at the same time have the flexibility to pin down package versions for each build? The mechanism that will assist...