I am in agreeance here and +1 on Option 2. Not only is the version "vetted" but also keeps our Go version for building consistent across services that are in the same repository which I think is of value as well. I know personally when I am developing I am probably not going to remember to switch my go version as I switch between services.
Michael On 11/20/19, 2:18 PM, "Rawlin Peters" <[email protected]> wrote: Hey all, The Go version for building Traffic Ops is currently pinned to 1.11 due to issues communicating with Riak when using 1.12 or 1.13. All of the other Go components are currently built using the version provided by the `golang` package from EPEL, which is currently 1.13.3. My question is: are we content keeping all non-TO Go components using the version provided by EPEL, since we haven't really identified an issue using 1.13 for those components (although I'm not sure they've really been "vetted" by anyone yet), or do we pin them back to 1.11 since that is the "vetted" version? These are some of the options I can see: 1. leave non-TO Go component builds as-is, they will use whatever version is provided by EPEL (might catch us off-guard, but we'll stay up to date by default) 2. pin the rest of the non-TO Go components to 1.11 (since that version is "vetted") then advance versions for components only after thorough testing 3. pin some Go components to 1.11, optimistically pin others to 1.13 if they're not as production critical Advancing components to new versions of Go seems like something that should be deliberate and tested, so I'd lean towards Option 2 for the time being. What option do you think is best? - Rawlin
