>- don't bother converting `/capabilities/{{name}}` from Perl to Go
But we still have to support those routes, until API 1.x is no longer
supported, which is far in the future.
We should still rewrite deprecated Perl routes in Go, just so we can get
rid of Perl sooner than that.
On Thu, Aug 15, 2019 at 12:54 PM Jeremy Mitchell <mitchell...@gmail.com>
wrote:
> Can you elaborate on what "deprecate" actually means? Here's what i think
> it means:
>
> - don't bother converting `/capabilities/{{name}}` from Perl to Go and
> adding some kind of deprecation message to the `/capabilities/{{name}}`
> Perl response.
>
> On Thu, Aug 15, 2019 at 12:15 PM ocket 8888 <ocket8...@gmail.com> wrote:
>
> > I recently marked a PR that rewrites the `/capabilities` endpoint in Go
> as
> > ready for review (https://github.com/apache/trafficcontrol/pull/3870)
> and
> > with it added handlers for PUT and DELETE. That means that
> > `/capabilities/{{name}}` will no longer do anything that `/capabilities`
> > does not, so is it alright if we deprecate it?
> >
> > There's also been some discussion about deprecating the ability to
> > create/modify/delete capabilities at all (mostly on that PR itself, atm).
> > I'd like to answer my above question before we get into that, though.
> >
>
