+1 on pinning the version on everything. Unpredictability and nondeterminism is bad.
I don't have a strong opinion on which version. Though later versions of Go frequently have performance improvements, sometimes huge ones, which can matter for our performance-intensive apps like the Monitor and Grove. On Wed, Nov 20, 2019 at 4:47 PM ocket 8888 <[email protected]> wrote: > uhh... never mind > > On Wed, Nov 20, 2019 at 4:34 PM ocket 8888 <[email protected]> wrote: > > > The routes don't need to be regular expressions though. That's a change > > that still needs to be made, and while it would have other benefits > beyond > > this whitelist/blacklist, it is a significant amount of work that may or > > may not be more than the work of getting regular expressions to work, so > > idk if you wanna do that but it's true. Then, as far as path parameters, > > you can just strip them before comparison by doing something like > > > > regex.MustCompile(`\{[^\}]+\}`).Replace(path, "") > > > > not actually familiar with that api, but the point is that comparisons > can > > be made to ignore path parameters probably pretty easily - as long as > they > > are just strings. > > > > On Wed, Nov 20, 2019 at 3:17 PM Hoppal, Michael < > > [email protected]> wrote: > > > >> 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 > >> > >> > >> >
