That was basically my struggle as well when using the TO Go client. It seemed like when I tracked with the head I was being broken all the time, so it does seem best to just vendor the client at some release version, then fix whatever breaks once the next release comes out and you have to upgrade the vendored client for some reason. Us trying to never break the TO Go client seems futile.
- Rawlin On Thu, Dec 5, 2019 at 3:24 PM Gray, Jonathan <[email protected]> wrote: > > In some of my applications, I just vendor the go client and associated > structs so they're stable and then I lean on the API version stability. When > I started developing them I could track with the head, but I got tired of > where/how the imports kept changing and to some degree function signatures > every time I went back to patch it. > > Jonathan G > > > On 12/5/19, 2:50 PM, "Rawlin Peters" <[email protected]> wrote: > > I think I've generally tried to operate in the mode of adding new > methods that do what I want and deprecating the old method. That's how > most of the "nullable" methods in the client came to be. > > While I like giving Go client users a heads up before they're going to > be broken (via a deprecation process), maybe we can just decide as a > community to make sure every breaking change in the Go client comes > with a decent line in the changelog. We already have to worry enough > about not making breaking changes to the TO API without notice, so I > could see the benefit of having mostly free rein to clean up and break > things in the TO Go client when necessary. > > The thing to be aware of though is that Go components like TM, TS, > grove, etc. all use the TO Go client, so you might end up breaking > them inadvertently if you're unaware. That said, we're constantly > changing the Go structs to add new fields and/or embed them for > versioning, and those are all technically breaking changes. So, I > don't think we can ever truly avoid breaking changes in the Go client, > unless we also heavily duplicate and deprecate lib/go-tc structs > (which would be madness). > > So I think that's a +1 from me, with the caveat that we should stay > aware of breaking changes and make sure they're noted in the changelog > for everyone to easily fix their code that we broke. > > - Rawlin > > On Thu, Dec 5, 2019 at 1:23 PM ocket 8888 <[email protected]> wrote: > > > > For what it's worth, I'm the reviewer and I'm +1 on being able to change > > them, though I've seen deprecation messages in there and so have avoided > > changing them myself in the past - in order to respect the deprecation > > process. > > > > > > On Thu, Dec 5, 2019 at 12:28 PM Hoppal, Michael > <[email protected]> > > wrote: > > > > > Hi, > > > > > > I am current rewriting a Perl route to Go ( PR -> > > > > https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/pull/4127__;!rx_L75ITgOQ!SgWGwRGA2PqYFtdbqPiGFXEJ0DNjp68wMrDwEElXBvcQFV8DIcPY7BQ7XvJbmkiAh5B9$ > ) and as part of the > > > rewrite I noticed some improvements I could make to the existing Go TO > > > Client methods for the endpoint. > > > > > > A reviewer asked the question if we should be changing signatures of > > > client functions without a deprecation period and I wanted to bring > it to > > > the list. > > > > > > I would personally lean towards allowing to change them. > > > > > > What are people’s thoughts? > > > > > > Thanks, > > > > > > Michael > > > > > > > >
