ATC components will no longer ever use an unstable API version again. Whether we make one or not, which isn't planned afaik. With the exception of Traffic Portal because nobody cares too much if that breaks a little.
All of that aside, an API 5.x doesn't necessitate ATC 8. We can add that in a 7.1. The issue is the removal of the deprecated 3.x API - THAT can't be done without an 8.x On Wed, Aug 24, 2022 at 9:53 AM Gray, Jonathan <jonathan_g...@comcast.com.invalid> wrote: > > That’s something to consider carefully on a case-by-case basis I believe. I > disagree though on continuing the idea of “unstable” api versions. Yes it > makes development easier, but we have experienced production issues related > to deploying mixed component versions where this bit us. > > Also, my statements around backward compatibility stem from our current > pattern of each time we add an API major rev, we remove one as well. That’s > what leads to the churn. It’s fine to bring new abilities and versions into > the mix, but continuing to remove things is what becomes costly as an outside > API consumer. I realize and appreciate that gets complicated when it comes > to shoehorning new concepts into old API versions or producing how old API > interactions work with new concepts. It might be a good idea to extend our > blueprint pattern to include those concerns specifically so that we consider > backward and forward compatibility during design instead of only API changes > required to make it work going forward. > > Jonathan > > From: Rawlin Peters <raw...@apache.org> > Date: Wednesday, August 24, 2022 at 9:22 AM > To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> > Subject: Re: [EXTERNAL] TC 8.0.0 > I think there may be some things coming up on the roadmap that might > require TO API 5.x. I can't say for certain, but I imagine projects > like DS Active Flag and MSO-by-default DSes may require some breaking > changes if we start those in the near future. So if we decide that we > don't want TO API 5.x, we may need to shelve those for a bit. That > said, when we introduce TO API 5.x, I would recommend keeping it > unstable again as we did for TO API 4.x in order to batch all the > breaking changes we want into a single major version. That may mean TO > API clients may choose to wait for the newest features with breaking > changes, but we could keep adding minor versions in parallel (e.g. > 4.1) so that TO API clients could have access to non-breaking API > changes sooner. > > - Rawlin > > On Tue, Aug 23, 2022 at 7:48 PM Jeremy Mitchell <mitchell...@gmail.com> wrote: > > > > So I, personally, would prefer a 7.1 with an API 4.1 to provide the > > backwards compatibility jonathan speaks of...unless there is something that > > absolutely requires api 5.x.. > > > > On Tue, Aug 23, 2022 at 10:53 AM Gray, Jonathan > > <jonathan_g...@comcast.com.invalid> wrote: > > > > > The lack of TO API backward compatibility support is causing me whiplash > > > as a consumer of that API and continues to add development and support > > > costs with each upgrade. > > > > > > Jonathan G > > > > > > From: Jeremy Mitchell <mitchell...@apache.org> > > > Date: Tuesday, August 23, 2022 at 10:10 AM > > > To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> > > > Subject: [EXTERNAL] TC 8.0.0 > > > I was just curious what the justification for TC 8.0 was. We are rolling > > > majors pretty quick (not sure that's a bad thing) and was just wondering > > > if > > > there was a "big" change i was unaware of and apologies for missing the > > > working group where this was probably discussed. > > > > > > I'm guessing i know the reason: TO API 5.x? which does worry me a bit > > > because i believe that means API 3.x will be deprecated / on the chopping > > > block. > > > > > > Jeremy > > >
