This sounds like a good plan, but I wonder if this is something we want to try to do before we cut the next release, or something we want to do after?
On Wed, Jul 10, 2019 at 10:31 AM Dan Kirkwood <dang...@gmail.com> wrote: > +1 > > On Wed, Jul 10, 2019 at 10:26 AM Fieck, Brennan <brennan_fi...@comcast.com > > > wrote: > > > +1 sounds fantastic to me > > ________________________________________ > > From: Rawlin Peters <raw...@apache.org> > > Sent: Tuesday, July 9, 2019 1:55 PM > > To: dev@trafficcontrol.apache.org > > 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 > > >
