Hi all, Looks like we had a fairly lively discussion here, and I'm late to the party. I've been contemplating everyone's positions, but I agree with the points Rawlin laid out in the initial email. We have been doing a lot of great work on the API front, but after observing much of the development, it feels like we have a complicated solution due to some inflexibility both with our approach itself and Golang. Due to this, we tend to put a lot of effort into supporting mixed compatibility for various clients, and that turns into quite a burden on developers. This burden manifests in a real tangible lack of progress when we should be focusing on completing the move to Golang.
In the interest of spending time where it's important and completing the Golang migration that has been far too drawn out, we should eliminate some of the goals we set forth with versioning which will simplify our approach. If we move to the major version scheme that Rawlin outlined, we won't have to worry about special cases where one minor version introduces new fields, and ensure that the prior version does not. This will reduce complexity in the code in several ways, and if we finally bite the bullet and move toward a strongly typed API and type safe everything, we will have no need for translation libraries that add overhead. We control the integration points between components and provide clients in our codebase today. As long as we do not break those integration points or clients, and provide documentation when we make a major version change that has a large impact on an API, we should provide guidance (release notes, etc) on the changes. We have limited development resources in our project and we should be focusing on things that really help us move forward. That means ripping the Perl out and not worrying about backwards compatibility for a whole class of clients that we a) don't know about or b) do not control. We can provide guidance to help people that don't use our clients, but we don't need to be on the hook to support every minor revision within a major release because some consumer *might* exist in the wild. Major changes would require a major revision and I think that's enough. -- Thanks, Jeff On Thu, Feb 14, 2019 at 4:38 PM Rawlin Peters <rawlin.pet...@gmail.com> wrote: > > I was referring to Brennan's proposal: > > Sure, but TO API v1 would only be implemented by TO v1 and TO API v2 only > > implemented by TO v2. > > I agree about the deprecation overlap. We need to support both API v1 > and v2 at the same time for at least one major release. > > - Rawlin > > On Thu, Feb 14, 2019 at 2:53 PM Gray, Jonathan > <jonathan_g...@comcast.com> wrote: > > > > Not quite. I'm saying our 1-3.x releases support the TO API versions > > 1.1-1.4 (speaking cumulatively). Hypothetically, should we come up with TO > > API 2.x in ATC 5.x you should not at the same time remove TO API 1.x in ATC > > 5.x. There needs to be a deprecation overlap of at least one major ATC rev > > to facilitate the transition to TO API 2.x. > > > > Jonathan G
