I don't think we plan to support 2 major versions of the API at all times. I thought we were only supporting 2 major TO API versions for one major release period (e.g. 4.x supports TO API 1.x and 2.x, once we release 5.0 it would only support 2.x).
However, we _do_ support the latest minor version of the last two major TC releases (currently 2.2 and 3.1?). Once we release 4.0 we will no longer support 2.2. - Rawlin On Tue, Dec 10, 2019 at 8:13 AM Jeremy Mitchell <[email protected]> wrote: > > +1 to that deprecation list. Just to clarify, those endpoints will continue > to function in 1.x and since it sounds like we plan to always support 2 > major versions of the api, they will continue to function until we get to > api 3.x which seems like ample time for clients to pivot. > > Jeremy > > On Mon, Dec 9, 2019 at 4:36 PM ocket 8888 <[email protected]> wrote: > > > +1 on that list > > > > It's not enumerated in the docs which endpoints will and won't return > > alerts - and everything returns alerts on errors - so clients are advised > > that any payload could have them. tl;dr I don't think adding alerts should > > cause a problem for compliant clients. > > > > On Mon, Dec 9, 2019, 10:09 Rawlin Peters <[email protected]> wrote: > > > > > Having been a part of that working group discussion, I'm +1 on this > > > list. I'd add that there might be some endpoints that don't currently > > > return an `alerts` array in the response, so adding a deprecation > > > alert to the actual response might not help much (because clients > > > won't be looking for a new unknown `alerts` field). For those kinds of > > > endpoints, I think we'd be ok skipping that part (the deprecation list > > > will also be in the changelog release notes). > > > > > > - Rawlin > > > > > > On Mon, Dec 9, 2019 at 7:06 AM Hoppal, Michael > > > <[email protected]> wrote: > > > > > > > > Hi, > > > > > > > > Based on the Traffic Ops API rewrite/versioning strategy it was decided > > > to promote the current Traffic Ops Golang implementation to TO 2.0 > > allowing > > > us to leave behind dangerous/deprecated routes(in Perl) in 1.x. > > > > > > > > The routes we deprecate will have a deprecation notice added to the > > > response and will be supported until TC 5.0. > > > > > > > > As part of the Traffic Ops working group last week we put together a > > > list of routes we think should be deprecated and not carried over to 2.0. > > > > > > > > The list and reasoning why we think it should be deprecated can be seen > > > at > > > > > https://gist.github.com/mhoppa/bb5341e6a0617aea9282265b840e0735#deprecation-routes > > > . > > > > > > > > These routes include: > > > > > > > > > > > > * /capabilities/{{name}} > > > > * /capabilities (Only POST, GET will be rewritten) > > > > * /cdns/{name}/configs/routing > > > > * /divisions/name/{{name}} > > > > * /federation_resolvers/{{ID}} > > > > * /hwinfo/dtdata > > > > * /parameters/validate > > > > * /regions/{{region}}/phys_locations > > > > * /parameters/{{id}}/profiles > > > > * /parameters/{{id}}/unassigned_profiles > > > > * /divisions/{{division}}/regions > > > > * /api_capabilities (Only POST, GET will be rewritten) > > > > * /api_capabilities/{{id}} > > > > * /servercheck/aadata > > > > * /stats_summary/create (Will be rewritten to be supported as a > > POST > > > on /stats_summary) > > > > * /types/trimmed > > > > * /deliveryservice_user > > > > * /deliveryservice_user/{{DSID}}/{{userID}} > > > > * /to_extensions/{{id}}/delete (Will be rewritten to be supported > > as > > > a DELETE on /to_extensions) > > > > * /cachegroup_fallbacks > > > > * /cdns/usage/overview > > > > * /riak/stats > > > > * /traffic_monitor/stats > > > > * /cdns/configs > > > > * /cachegroup/{{paramID}}/parameter > > > > * /cachegroups/{{paramID}}/parameter/available > > > > * /deliveryservices/{{id}}/state > > > > > > > > Thanks, > > > > > > > > Michael > > > > >
