Re: [EXTERNAL] Re: Traffic Ops Route Deprecation Strategy

["Gray, Jonathan" <Jo...@comcast.com>]

Agreed with Rob.  API versioning aside, how does that look from our native SDK implementations?  Do we have native client code for those routes?  Do we have project code dependent on that native code?

Jonathan G


On 11/12/19, 9:05 AM, "Robert O Butts" <ro...@apache.org> wrote:

    Whether we rewrite a route in Go is an implementation detail. To the
    interface, to users, it doesn't matter whether a route is rewritten or not.

    But our API follows Semantic Versioning, in order to not break users. We
    can't just remove endpoints that some of us don't use, and assume other
    people don't, maybe people who never speak up on the mailing list. We'll
    never gain a big userbase if we keep breaking users.

    Per the _project_ SemVer, once we have API 2.0, we can deprecate API 1.x,
    and in the next major _project_ release, remove API 1.x. Irrespective of
    Perl or Go.

    My big concern is, API 2.0 is a big project. How long has the rewrite to Go
    taken? Do we really believe designing and implementing a completely new API
    will be any less time?

    I don't want killing Perl to have to wait on that.

    I know it feels like a waste to rewrite routes that you don't use, and
    probably few people do. But that's the cost of a stable project. How many
    "deprecated" routes are there? If it comes down to taking the development
    time to rewrite them so we can kill Perl faster, or leaving Perl around, I
    vote we just do the work and kill Perl.

    >If we don't rewrite them, then Perl will last until API 2.0 has been
    designed, released and then *another full major release cycle*. That's way
    too long to have two codebases for the same component, IMO, especially
    since the rewrite is already 50% complete.

    +1


    On Tue, Nov 12, 2019 at 8:54 AM ocket 8888 <oc...@gmail.com> wrote:

    > I vote that by and large we DO rewrite them, with exceptions for routes
    > that just plain don't work, even in Perl. Those are few, though.
    >
    > If we don't rewrite them, then Perl will last until API 2.0 has been
    > designed, released and then *another full major release cycle*. That's way
    > too long to have two codebases for the same component, IMO, especially
    > since the rewrite is already 50% complete.
    >
    > On Tue, Nov 12, 2019 at 8:43 AM Hoppal, Michael <
    > Michael_Hoppal@comcast.com>
    > wrote:
    >
    > > As the Traffic Ops API is being rewritten from Perl to Golang there has
    > > been several routes that have been deprecated and probably more to come.
    > >
    > > In the deprecation efforts I have seen two strategies:
    > >
    > >
    > >   *   The route IS NOT rewritten from Perl to Golang and a deprecation
    > > notice is added to the alert response in the Perl handler
    > >   *   The route IS rewritten from Perl to Golang and a deprecation notice
    > > is added to the alert response in the Golang handler
    > >
    > > I think we should have consistency in our approach and wanted to get
    > > people’s thoughts.
    > >
    > > I would vote that we do not rewrite a deprecated route from Perl to
    > Golang.
    > >
    > > Thanks,
    > >
    > > Michael
    > >
    >