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://github.com/apache/trafficcontrol/pull/4127 ) 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 > > > >
