> Yes it makes development easier It's not just about API development, it's about all the API consumers too. API instability actually reduces "whiplash" for consumers of the API, because it reduces major version churn. Therefore, consumers will have fewer upgrades to jump through overall. Not to mention, there are certain features we've implemented or want to implement that would be completely infeasible if we had to maintain backwards compatibility all the way back to the introduction of an API. Layered Profiles are an example of that. We can't actually start using Layered Profiles until we allow more than 1 profile to be assigned to a server, and we can't safely allow that until API 3.x is removed, right?
> we have experienced production issues related to deploying mixed component > versions where this bit us The use of unstable, in-development API versions in order to start using new features sooner will always come with the risk of needing to coordinate upgrades with consumers. That is a reason not to use an unstable API, not a reason to not have unstable APIs in the first place. - Rawlin On Wed, Aug 24, 2022 at 9:54 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 > > >
