Hey all, Now that we've upgraded all our Go components to use v1.11, I believe we can start using Go modules [1] to start managing our Go dependencies for the project instead of vendoring our Go dependencies directly into our repo.
Does anyone have any experience using Go modules yet? After doing some quick research on Go modules, I think we would just have to identify the commit hash of each of our Go dependencies at the time they were cloned into our repo and pin the versions of our dependencies to those commit hashes in the go.mod file (since I believe the dependencies were just cloned from the head of master and might not necessarily line up with a SemVer release tag). I think these would be the steps (which could each be broken down into multiple PRs if necessary): Step 1: identify commit hashes of our current dependencies, implement Go modules to manage them at our existing vendored versions, remove the vendored code from the repo, and fix the build processes to use the new Go module tooling. By the end of this step, the dependencies we pull down for the build should match our existing vendored dependencies exactly. Step 2: reevaluate the current versions of our dependencies in order to update them to compatible SemVer release tags provided by the dependency (rather than a specific commit hash) if necessary. Once pinned to specific SemVer versions, it should be easy to always keep our Go dependencies up to date, although some dependencies might not have implemented the required SemVer release tagging yet. Does this sound like a reasonable plan to everyone? I don't have any experience using Go modules yet, so if anyone has experience with them and has better ideas I'd love to get their input on this. Unless there are any objections within the next few days, I'll assume everyone is generally on board with Go modules, and someone could start working on this after that time. Thanks, Rawlin [1] https://github.com/golang/go/wiki/Modules
