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 > >
