+1 On Wed, Jul 10, 2019 at 10:26 AM Fieck, Brennan <[email protected]> wrote:
> +1 sounds fantastic to me > ________________________________________ > From: Rawlin Peters <[email protected]> > Sent: Tuesday, July 9, 2019 1:55 PM > To: [email protected] > Subject: [EXTERNAL] Go dependency management > > 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://protect2.fireeye.com/url?k=5da6d7fab5a4c93e.5da6f04e-17c163f89d22e415&u=https://github.com/golang/go/wiki/Modules >
